Changes between Version 10 and Version 11 of MapGuideRfc19

Timestamp:

Apr 13, 2007, 1:41:19 PM (17 years ago)

Author:

brucedechant

Comment:

--

MapGuideRfc19

@@ -23 +23 @@
 == Overview ==
 
-The purpose of this RFC is to support a way to limit the # of concurrent FDO connections to a specific provider. By allowing for a limit to the # of concurrent FDO connections the server can support single threaded providers and any provider that has a limit on the # of client connections (ie: Oracle, etc...).
+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 restriction the # of concurrent FDO connections. This needs to be addressed.
+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 ==
@@ -33 +35 @@
 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
@@ -47 +50 @@
 == 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 ==