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:
[hidden email] [mailto:
[hidden email]] 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:
[hidden email]
> [mailto:
[hidden email]] 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
>
[hidden email]
>
http://lists.osgeo.org/mailman/listinfo/mapguide-internals>
> _______________________________________________
> mapguide-internals mailing list
>
[hidden email]
>
http://lists.osgeo.org/mailman/listinfo/mapguide-internals> _______________________________________________
> mapguide-internals mailing list
>
[hidden email]
>
http://lists.osgeo.org/mailman/listinfo/mapguide-internals>
>
_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals
