[mapguide-internals] RE: The pinned connection

[Trevor Wekel]

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