[mapguide-internals] RE: The pinned connection

[Haris Kurtagic]

+1
Haris

-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org
[mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Trevor
Wekel
Sent: Sunday, October 25, 2009 10:59 AM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] RE: The pinned connection

I personally like

conn = MgFeatureService.GetFeatureConnection(resourceId);
conn.BeginTransaction();
conn.CommitTransaction();
conn.RollbackTransaction(); // I think rollback is a single word in database
lingo


I did a quick check and many databases do not support nested transactions so
having a separate transaction object could lead to illegal use cases.  From
what I can tell, having a single transaction per connection is more "SQL"
like and should be easier to support for all database providers.

I'm sure an Fdo expert will jump in here and correct me if I'm wrong...


Thanks,
Trevor

  
-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org
[mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of UV
Sent: October 24, 2009 5:59 AM
To: MapGuide Internals Mail List
Subject: Re: [mapguide-internals] RE: The pinned connection

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
>
>   

_______________________________________________
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