[mapguide-internals] RE: The pinned connection

[UV]

I have a proposal for further integration of RFC78 and RFC86.
This just takes the one from Haris and adds a few more methods to stay 
compatible.


I like an additional transaction object. With overloading this would 
support the original RFC78 as well (unless there is a SWIG limitation?)
If MgTransaction is already implemented we can us it in the way below.
 
This is better for the same reason as exposing the dedicated connection 
via the API as it makes the DB access code more explicit.
This can be integrated like this and makes very clear and legible code:

Full support also for renaming the connection to FeatureConnection or 
DedicatedFeatureConnection which seems more descriptive english.

MgFeatureConnection conn = nullptr;
MgTransaction tran = nullptr;

try
{
    conn = MgFeatureService.GetFeatureConnection(resourceId);
    conn.BeginTransaction(); // <--- added
    // or 
  	  tran = conn.BeginTransaction(); // <--- minimal compatible change
			/// or 
		    tran = MgFeatureService.StartTransaction(resourceId); /// alternative from RFC78

    MgFeatureService.ExecuteSql(resourceId, sql statement1, conn);
    MgFeatureService.ExecuteSql(resourceId, sql statement2, conn); 
    MgFeatureService.UpdateFeatures(resourceId, MgFeatureCommandCollection,conn);

			/// maybe the connection can be simply overloaded       \/\/
			MgFeatureService.ExecuteSql(resourceId, sql statement1, tran); 
			MgFeatureService.ExecuteSql(resourceId, sql statement2, tran); 
			MgFeatureService.UpdateFeatures(resourceId, MgFeatureCommandCollection, tran);

			/// or if not overloaded (but then its not pretty anymore
			MgFeatureService.ExecuteSql(resourceId, sql statement1, null, tran); 
			MgFeatureService.ExecuteSql(resourceId, sql statement2, null, tran); 
			MgFeatureService.UpdateFeatures(resourceId, MgFeatureCommandCollection, null, tran);

    conn.CommitTransaction();  // <--- added
		    	tran.Commit();	/// alternative

    conn.Release();
}
catch(...)
{
    conn.RollBackTransaction();  // <---- added 
		    if(nullptr != tran) tran.Rollback();   /// alternative		
}


Trevor Wekel wrote:
> I like this solution.  It associates the transaction with the connection and allows both the execute and the update to occur on the same connection with or without transaction support.  It effectively rolls 2 RFCs into one.
>
> I would personally prefer MgFeatureConnection over MgPinnedConnection because the "Feature" connection is created from "Feature" service.  MgConnection is ambiguous because MapGuide also opens TCP/IP connections from web tier to server.
>
> MgFeatureConnectionNotAvailable would be an appropriate throw from MgFeatureService.GetFeatureConnection()
>
>
> -----Original Message-----
> From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Haris Kurtagic
> Sent: October 24, 2009 4:03 AM
> To: 'MapGuide Internals Mail List'
> Subject: RE: [mapguide-internals] RE: The pinned connection
>
> I was writing about just one solution ( I hope that my English doesn't add
> some misunderstanding :) ).
>
> As you wrote first example is what I was suggesting for first RFC68.
> If functionality for RFC78 is done (or is in plan) I would extend connection
> so you would start transaction on connection.
> Then we would not have two parameters to ExecuteSql but just one.
> I will try to explain in code, will just add to your first example :
>
> MgPinnedConnection conn = nullptr;
> try
> {
>     conn = MgFeatureService.GetPinnedConnection(resourceId);
>     conn.BeginTransaction(); // <--- added
>     	
>     MgFeatureService.Update...
>     MgFeatureService.Update...
>     MgFeatureService.ExecuteSql(resourceId, sql statement1, conn);
>     conn.CommitTransaction();  // <--- added
>     MgFeatureService.ExecuteSql(resourceId, sql statement2, conn); 
>     MgFeatureService.UpdateFeatures(resourceId, MgFeatureCommandCollection,
> conn);
>     conn.Release();
> }
> catch (NoPinnedConnectionAvailableException ex)
> {
> .
> }
>
>
> And I would have suggestion to change the name from MgPinnedConnection to
> MgConnection or MgFdoConnection or... To me this pinn.. sounds unnecessary
> it is just MG/FDO connection to underlying data source.
>
>
> Haris
>
>  
> -----Original Message-----
> From: mapguide-internals-bounces at lists.osgeo.org
> [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Leaf Li
> Sent: Saturday, October 24, 2009 2:40
> To: mapguide-internals at lists.osgeo.org
> Subject: [mapguide-internals] RE: The pinned connection
>
> Hi Haris,
>
> If my understanding is correct, you propose two solutions in our discussion.
> One is simpler. This solution will not affect MgTransaction.
>  
> MgPinnedConnection conn = nullptr;
> try
> {
>     conn = MgFeatureService.GetPinnedConnection(resourceId);
>
>     MgFeatureService.ExecuteSql(resourceId, sql statement1, conn); 
>     MgFeatureService.ExecuteSql(resourceId, sql statement2, conn); 
>     MgFeatureService.UpdateFeatures(resourceId, MgFeatureCommandCollection,
> conn);
>     conn.Release();
> }
> catch (NoPinnedConnectionAvailableException ex)
> {
> .
> }
>  
>  
> Another is in this way. It affects MgTransaction. So we have to change
> current design of MapGuide RFC 78 - Enhance transaction capability to
> Feature Service. For example, transaction isn't started, committed and
> rollbacked by MgFeautreService. It is done by MgPinnedConnection.
>  
>  
>   
>> Conn1 = Open(FeatureSourceId)
>> Execute SQL(Conn1,..)
>> Open(Conn2)
>> Execute SQL(Conn2,..)
>> Open(Conn3)
>> Conn3.StartTransaction()
>> Conn3.Committ()
>> Execute SQL(Conn3,..)
>> Close(conn3)
>> Close(Conn2)
>> Close(Conn1)
>>     
>  
>  
> For the second, it think it is the perfect way. I think you are talking
> about the first solution in the email below. There are some issues for the
> first solution. One of issues is how to execute a transaction against a
> existing pinned connection? Maybe we need to add the following method.
> Right?
>  
> ExecuteSqlNonQuery(MgResourceIdentifier, string, MgTransaction,
> MgPinnedConnection)
>  
> However, MgTransaction already occupies a connection when calling
> FeatureService::BeginTransaction(.). How do we handle them in this time?
>
> So if we want to return a MgPinnedConnection object to users, we should use
> the second solution to start a transaction instead of
> FeatureService::BeginTransaction(.).
>
> Thanks,
> Leaf Li
>
>   
>> Hi Li,
>>
>> I think that more work is needed for API as proposed in RFC because there
>>     
> is
>   
>> functionality around pinning and unpinning connections and keeping track of
>> those. All functionality for the solution I would prefer is already there,
>> it is just about the way how is it exposed.
>>
>> It does changes API but in same way as it changes with transaction RFC78.
>> My suggestion would be just to change that one and instead of adding
>> transaction as new parameter add connection. And then on connection just
>>     
> use
>   
>> transaction functionality which was developed for RFC78.
>>     
>
> Haris_______________________________________________
> mapguide-internals mailing list
> mapguide-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>
>
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>
>