MapGuide RFC 19 - Concurrent FDO provider connections

This page contains a change request (RFC) for the MapGuide Open Source project. More MapGuide RFCs can be found on the RFCs page.

Status

RFC Template Version	(1.0)
Submission Date	Apr 13, 2007
Last Modified	Bruce Dechant Timestamp
Author	Bruce Dechant
RFC Status	Draft
Implementation Status	Pending
Proposed Milestone	1.2
Assigned PSC guide(s)	Robert Bray
Voting History
+1
+0
-0
-1

Overview

The purpose of this RFC is to support a way of limiting the # of concurrent FDO provider connections to a specific provider. By allowing for a way to limit the # of concurrent FDO provider connections the server can support single threaded providers and any provider that has a limit on the # of client connections (ie: Oracle, etc...).

Motivation

Currently, the server only supports FDO providers that support a thread-per-connection or better thread model. Although not ideal there is no support for single-threaded providers or for restricting the # of concurrent FDO provider connections. This needs to be addressed.

Note: The existing releases of MapGuide did not check the provider thread model and subsequently allowed single-threaded providers to be used albeit in an unsafe manner.

Proposed Solution

The server will be modified to allow for a way to specify a default maximum # of concurrent FDO provider connections and for a way to specify a specific # of concurrent FDO provider connections for a specific provider.

Example settings inside the serverconfig.ini file:

# DataConnectionMaxConcurrent          Default # of allowed FDO connections per provider
#                                      0 < Value <= 100
# DataConnectionMaxConcurrentCustom    Custom # of allowed FDO connections for specified provider
#                                      0 <= Value <= 1024
#                                      Example: OSGeo.SDF:10,OSGeo.SHP:10
DataConnectionMaxConcurrent        = 20
DataConnectionMaxConcurrentCustom  = OSGeo.SDF:10

The server will also check the thread model supported by the underlying FDO provider and if it is single-threaded then the maximum # of concurrent FDO provider connections will be limited to 1 regardless of the above settings.

Implications

If this RFC is not implemented there will be no support for single-threaded providers or for restricting the # of concurrent FDO provider connections.

The biggest caveat for implementing this RFC is that if an application developer does not call the Close() method on the appropriate reader then the server still thinks that someone is using the FDO provider connection and therefore an active concurrent FDO provider connection still exists. This makes single-threaded providers very sensitive to this because only 1 FDO provider connection at a time is allowed.

Note: Even if the application developer forgets to call the Close() method on the appropriate reader that php, java, .Net will eventually call it when the object goes out of scope. However, this will not always be immediate due to garbage collection and therefore there will be a delay that may impact FDO provider connections especially single-threaded providers.

Test Plan

Test concurrent access to various FDO providers. Test single threaded FDO provider, example GDAL.

Funding/Resources

Autodesk to provide resources / funding.