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.
|RFC Template Version||(1.0)|
|Submission Date||Apr 13, 2007|
|Last Modified||Bruce Dechant Timestamp|
|Assigned PSC guide(s)||Robert Bray|
|Voting History||April 20, 2007|
|+1||Andy, Bob, Bruce, Haris, Jason, Tom|
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...).
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.
The server will be modified to extend on the already existing "DataConnectionPoolSize" and "DataConnectionPoolSizeCustom" configuration properties. If the connection pool is disabled or a provider is listed as excluded from connection pooling the above settings will still be used to limit the # of concurrent FDO provider connections.
Example settings inside the serverconfig.ini file:
# DataConnectionPoolSize Default # of FDO connections to allow per provider # These are cached if the data connection pool is enabled # and the provider is not excluded from the cache. # 1 < Value <= 100 # DataConnectionPoolSizeCustom Custom # of FDO connections to allow for the specified provider # These are cached if the data connection pool is enabled # and the provider is not excluded from the cache. # 1 <= Value <= 1024 # Example: OSGeo.SDF:10,OSGeo.SHP:10 DataConnectionPoolSize = 20 DataConnectionPoolSizeCustom = 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.
To clarify how this works the following is the order of precedence for what value to use for limiting the maximum # of concurrent connections.
- If the provider thread model is single-threaded then the # of concurrent connections will be limited to 1 regardless of what the above settings have. This is to ensure server stability.
- The # of concurrent connections specified in the "DataConnectionPoolSizeCustom" property for the specified provider will be used.
- The # of concurrent connections specified in the "DataConnectionPoolSize" property will be used.
If the server is unable to create a new concurrent connection to a provider that has no more connections available and error will be logged to the server's error log.
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 concurrent access to various FDO providers. Test single threaded FDO provider, example GDAL.
Autodesk to provide resources / funding.