[mapguide-internals] The pinned connection

[Leaf Li]

It seems we confuse transaction and pinned connection. So before I answer you question, l would like to introduce sameness and difference between them a little bit.

Sameness:
1. Both transaction and pinned connection will exclusively use one FDO connections in FDO connection pool.
2. Both transaction and pinned connection will maintain connection state information. 

Difference:
1. Transaction will guarantee that operations executed in one transaction are atomic. So it has commit and rollback method. But it doesn't make sense for pinned connection. Pinned connection just guarantee that operations use the same FDO connection. Pinned connection doesn't want commit and rollback operations.
2. One transaction may do something on the DRBMS server when opening a transaction. Changes in one transaction isn't visible for operations which aren't in the same transaction before committing transaction. It isn't true for pinned connection. Changes in one pinned connection can be visible for other users. The connection state information that transaction and pinned connection maintain is different.

What we need is a pinned connection. Users can use the same connection when calling methods
ExecuteSqlQuery
ExecuteSqlNonQuery
UpdateFeatures
SelectFeatures
SelectAggregate
......

For example, we can call method ExecuteSqlNonQuery against Oracle feature source to execute the following statements, 
LOCK TABLE ...
ALTER SESSION ...
CONNECT AS SYSDBA
......

Those connection state information should be bound to a users session. For example, after one user session execute "CONNECT AS SYSDBA", this FDO connection should be bound to this session and can't be used by other users session. Otherwise, other users may have SYSDBA access right by using this FDO connection.

This is the motivation of this RFC. It happen we use a nested transaction (MapGuide and FDO doesn't support nested transaction) sample and a nested data reader sample to show intention. So it may result in some confusing between transaction and pinned connection. Hope it is clear now.

Thanks,
Leaf Li


>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