[mapguide-internals] RE: The pinned connection (Leaf Li)

[UV]

I would like to ask for some more clarification!

The first example given in the RFC86 is actually the use of pooled 
connections for something that should be in a transaction.
So this is not a good example for a dedicated connection but for the use 
of a transaction context.

The other example is about too many admin connections. This can be 
solved by using one dedicated admin connection always.

So what is the actual need for this? Can we get an example on a more 
abstract use case level ?

Why can this not be solved with a limit of dedicated connections per 
user session?
Why does this need to be exposed to the API?

Those questions have somehow not been answered yet.



Leaf Li wrote:
> All,
>
> Now I think we already understand the current concerns on RFC 86 very clearly. I agree that solution what Haris proposes is clearer and more flexible. I also want to reiterate pinned connection is an edge case that should not be used unless it's absolutely necessary. Let's compare this solution with current solution and then make a decision.
>
>   
>> 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)
>>     
>
> Solution what Haris proposes
> Strength:
> 1. Clear and consistent
> 2. Flexible: It is possible for users to create more than one pinned connection for a feature source in one user session. However we don't have a requirement to create more than one pinned connection for a feature source in one user session.
> Weakness:
> 1. Lots of changes to API.
> 2. Need more efforts. Maybe we don't have enough resources to finish it in this release cycle. If we do it in next release cycle, transaction related API is already released. It will result in other inconsistence in next release cycle if we can't finish it in this release cycle.
>
> Current Solution:
> Strength:
> 1. Small changes to API.
> 2. Much less effort. We can finish it in this release cycle.
> Weakness:
> 1. Not as Clear as solution what Haris proposes. However, it works.
>
> So now our question becomes whether we want to a perfect solution that we may not afford or a less perfect solution that we can afford.
>
> I think we need make a decision according to our RFC process.
>
> If according to our RFC process we needn't vote again, Haris can continue to vote. 
> If we need vote again, let's do it again.
>
> Thanks,
> Leaf Li
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>
>