[mapguide-internals] RE: The pinned connection

[Leaf Li]

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