[mapguide-internals] Motion: vote RFC 86 - other approaches

UV uvwild at googlemail.com
Fri Oct 16 18:29:13 EDT 2009


I think the pinned connections RFC86 should be integrated with 
introducing the transaction context RFC78.
   
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.


Tom Fukushima wrote:
> Hi Harris,
>
> These concerns should be raised during the review period.
>
> I don't understand your solution, could you provide more details?
>
> Thanks
> Tom
>
> -----Original Message-----
> From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Haris Kurtagic
> Sent: Thursday, October 15, 2009 5:01 PM
> To: 'MapGuide Internals Mail List'
> Subject: RE: [mapguide-internals] Motion: vote RFC 86 - the Pinned connection
>
> Sorry if I am late, I have concerns regarding this RFC. What would happen if
> there are more pinnes in one session or more connections wanted to be run in
> same session ? Also, If I remember correctly there is link between reader
> being closed and connection released ? If that is case what would happen in
> case of multiple readers?
>
> In my opinion better solution would be to be able to "get" connection from
> server and then use that connection. In such way user would be able to have
> any number of connections and use them in any way.
> Also that looks to me like cleaner and more understandable solution.
>
> If I am to late then I vote
> -0 
>
> Haris
>
> -----Original Message-----
> From: mapguide-internals-bounces at lists.osgeo.org
> [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Tom
> Fukushima
> Sent: Thursday, October 15, 2009 19:48
> To: MapGuide Internals Mail List
> Subject: [mapguide-internals] Motion: vote RFC 86 - the Pinned connection
>
> It looks like the issues and comments on this RFC have now been addressed
> and so I motion for a vote on
>
> RFC 86 - the Pinned Connection
> http://trac.osgeo.org/mapguide/wiki/MapGuideRfc86
>
>
> +1 Tom
>
> Thanks
> Tom
> _______________________________________________
> 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
>
>   



More information about the mapguide-internals mailing list