[mapguide-internals] RE: mapguide-internals Digest, Vol 34, Issue 15

[Leaf Li]

Hi UV,

Thanks for your feedbacks. I add my comments in lines.

>I think the pinned connections RFC86 should be integrated with 
>introducing the transaction context RFC78.

[Leaf] It is a little related but different. Operations in the same
Transaction will use the same FDO connection. This behavior is 
similar to pinned connection. 

But pinned connection has nothing to do with transaction. 
For example, we just want to have the same connection for 
the two feature reader. It has nothing to do with transaction. 
Commit and rollback operation doesn't make sense here.

    MgSqlDataReader reader1 = featureService.ExecuteSqlQuery(featureSourceId, commandText, mgParameters, null);
    while (reader1.ReadNext())
    {
        MgSqlDataReader reader2 = featureService.ExecuteSqlQuery(featureSourceId, commandText, mgParameters, null);
        while (reader2.ReadNext())
        {
            ......
        }
        reader2.Close();
        reader2.Dispose();
    }
    reader1.Close();
    reader1.Dispose();

Moreover, one transaction may do something on the DRBMS server 
when opening a transaction. This has consequences such as updates
are only visible in this transaction, and data gets locked.
All of those behaviors aren't what we want.

   
>Goal: Expose a threadsafe transaction context to the API.
>
>Approach:
>At the begin of the transaction the connection manager should 
>automatically acquire a dedicated "pinned" FDO Connection for this 
>transaction.
>- we can now consider providing an additional property to the 
>transaction API to block parallel reader connections or not.
>At the end after the commit of the transaction the FDO connection will 
>be released.
>
>This behaviour permits the user code the sequencing of multiple db 
>writes always reusing the same FDO connection until commit.
>
>Now we need to decide how to deal with a parallel reader on a parallel 
>FDO connection from the pool.
>The use of a parallel FDO connection should be off by default during the 
>transaction.
>We could permit parallel reader threads which then possibly return 
>different state than the comitted state after the transaction.
>I can also imagine scenario where the reader would block until the 
>transaction is complete creating a possible dead lock.
>This needs some fun testing to verify so this needs clear warnings in 
>the API doc.
>
>Generally the dedicated FDO connection issue is too closely connected to 
>the transaction context
>and should not be exposed separately in the API.
>
>If this behaviour is accepted then we can discuss implementation details.

Thanks,
Leaf Li