[mapguide-internals] RE: The pinned connection

[Leaf Li]

I think I give more examples in another email the day before yesterday. Let me summarize it again.

1. When executing a SQL statement, it may execute connection state. Those connection state should be visible for other users. For example, executing the following statement against a Oracle datastore.
   savepoint
   commit
   rollback to
   alter session
   connect as sysdba
   ......
The connection should be bound to current users session after executing those statement. Otherwise, it will result in some issues. 
In MapGuide RFC 86, it happen to use "savepoint", "commit" and "rollback" to show this issue. There are the same issues for "alter session", "connect as sysdba" and some of SQL statements.

2. When using nested reader shown in RFC 86, multiple FDO connections are used. If users pin connection before creating reader, it can reduce connections used by one user session and make more connecitons avaiable to other users sessions.

Hope it explains the motivation of this RFC.

Thanks,
Leaf Li


>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