Changes between Version 10 and Version 11 of MapGuideRfc86

Timestamp:

Sep 24, 2009, 7:48:33 PM (15 years ago)

Author:

leaf

Comment:

--

MapGuideRfc86

@@ -29 +29 @@
 Currently MapGuide Server maintains an FDO connection pool in order to improve performance. Once MapGuide Server receives a request to access data in a feature source, it will try to find an available FDO connection in FDO connection pool. It avoids exhausting FDO connections to the underlying RDBMS and improves performance of MapGuide Server when many users use MapGuide Server in the same time. However, it means that one user session may use the different FDO connection for the same feature source at the different time. Sometimes, it will result in some unexpected errors. Let’s take a look at one example.
 
+In the example above, it is possible that FDO connections used by executing SQL statements "SAVEPOINT X", "ROLLBACK TO X" and "COMMIT" are completely different FDO connections. If so, it will result in an error when executing SQL statement "ROLLBACK TO X" or "COMMIT".
+Sometimes, it can be resolved by passing an MgTransaction instance when executing SQL statements because MapGuide Server will guarantee that operations in the same transaction use the same FDO connection. However, it still has the following two issues. 
+  * There are only three methods supporting transaction, MgFeatureSerive::UpdateFeatures, MgFeatureSerive::ExecuteSqlQuery and MgFeatureSerive::ExecuteSqlNoQuery. 
+* MgFeatureSerive::BeginTransaction will do something on the DRBMS serverwhen opening a transaction. This has consequences such as updates are only visible in this transaction, and data gets locked.
+
 {{{
     MgSqlDataReader reader1 = featureService.ExecuteSqlQuery(featureSourceId, commandText, mgParameters, null);
@@ -44 +49 @@
     reader1.Dispose();
 }}}
+
+So we need a mechanism to bind an FDO connection to one user session. Then MapGuide always uses this bound FDO connection when executing any FDO commands for the same feature source in this session. Moreover, we need provide a mechanism to unbind the FDO connection which is bound to one user session so that FDO connection is available for other user sessions after the user doesn’t need to bind the FDO connection to his session.
 
 == Proposed Solution ==