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

[UV]

Hello,

My general advice is to avoid extending the API if there is any possible 
logic which
do the job without exposing such internal states to the API.
So the question is if there is any business logic to decide this?

I think one important thing missing in RFC86 is a complete list of use 
cases this is wanted for.
(Maybe we should focus more on the use cases to be part of any RFC to 
help further evaluation of it. )

The use case/example in RFC86 looks to me like a transaction which 
should reuse the same FDO connection
for the same user session. That was the start of my comment. I believe 
using a dedicated FDO connection makes
a lot of sense for the Transactions.

So what are the other use cases?

We can easily agree that the FDO connection pool needs to be a little 
smarter than it is.
Exposing those things to the API feels wrong.
So can someone help to complete the use cases so we can write the logic 
to manage the FDO connection pool?





In this case we have to consider single user and multi user scenarios.

Haris Kurtagic wrote:
> Leaf, UV,
>
> To be able to use only one "pinned" connection in session is unnecessary
> restriction to application.
>
> I think UV comment was correct that this RFC is connected to RFC78 (thanks
> UV to pointing it out).
> Instead of adding parameter to set transaction in execute sql functions it
> should be better to use connection as parameter.
> On that connection transaction is started or not, which depends of'course on
> application.
>
> In such case you can any number of transaction, readers, "pinned"
> connections whatever.
> Application is in control how and for what wants to use them. In that case
> there is no confusion what is pinned what is in transaction etc...
>
> 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: Monday, October 19, 2009 9:28
> To: mapguide-internals at lists.osgeo.org
> Subject: [mapguide-internals] RE: mapguide-internals Digest, Vol 34, Issue
> 15
>
> Hi Haris,
>
> Thanks for your feedbacks. I add my comments in lines.
>
>   
>> 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?
>>     
>
> [Leaf] Two pinned connections aren't allowed to created in one session. Once
> users call PinConnection(), this method do nothing when calling it again
> till 
> calling UnpinConnection or pinned connection is time-out.
>
>   
>> 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.
>>     
>
> [Leaf] Yes. It can be a solution. To a certain extent, it is cleaner. To a 
> Certain extent, it may result in some confusing. We have to overload most of
> feature service methods to add a new parameter 'MgFdoConnection'. Users can
> use pinned connection and unpinned connection in the same time. If users
> forget to use the pinned connection in a situation where a pinned connection
> should be used, it is difficult for users to debug what's wrong with the 
> application.
>
> Thanks,
> Leaf Li
> _______________________________________________
> 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
>
>