[mapguide-internals] RE: The pinned connection

[Haris Kurtagic]

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