OSGeo.org › OSGeo Software and Data Projects › MapGuide Open Source › MapGuide Internals

The Pinned Connection

33 messages

1 2

Leaf Li

The Pinned Connection

Reply Threaded

Harris,

Badreddine's description is absolutely right. MapGuide server will keep track of the association between (session,fsdid,connection). What I mean is that two pinned connections aren't allowed to created in one session for the same feature source. If users pass a different feature source id when calling MgFeatureService::PinConnection(), feature service will create pinned connection for current session and this feature source.

Thanks,
Leaf Li

>Harris,
>
>You should be able to pin more than one connection per session. The new API takes a feature source id and an application can create any number of those ids and pin their associated connections. My >understanding is that the server will keep track of the association between (session,fsdid,connection). Even though the a fsid may refer to the same connection parameters as an existing fsid, if >PinConnection is called using the new fsid, then a new connection will be pinned. Of course, you can have a third fsid to the same data and decide not to pin the associated connection. In that case you >just grab a connection from the pool as you do today. I assume that pinned or not, the connection will stay around if a reader is still using it.
>
>Badreddine
_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

Haris Kurtagic

RE: The Pinned Connection

Reply Threaded

>From RFC it looks even if you are able to "pin" more connections for same
feature source, you don't know which connection is used in which
ExecuteSql...

I think if " void PinConnection(MgResourceIdentifier featureSourceId) = 0;"
would return connection then that id (or class) should be used in
ExectueSql.. functions.
Also on that connection it would be possible to execute Transaction commands
to address RFC78

Haris

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Leaf Li
Sent: Tuesday, October 20, 2009 5:00
To: [hidden email]
Subject: [mapguide-internals] The Pinned Connection

Harris,

Badreddine's description is absolutely right. MapGuide server will keep
track of the association between (session,fsdid,connection). What I mean is
that two pinned connections aren't allowed to created in one session for the
same feature source. If users pass a different feature source id when
calling MgFeatureService::PinConnection(), feature service will create
pinned connection for current session and this feature source.

Thanks,
Leaf Li

>Harris,
>
>You should be able to pin more than one connection per session. The new API
takes a feature source id and an application can create any number of those
ids and pin their associated connections. My >understanding is that the
server will keep track of the association between
(session,fsdid,connection). Even though the a fsid may refer to the same
connection parameters as an existing fsid, if >PinConnection is called using
the new fsid, then a new connection will be pinned. Of course, you can have
a third fsid to the same data and decide not to pin the associated
connection. In that case you >just grab a connection from the pool as you do
today. I assume that pinned or not, the connection will stay around if a
reader is still using it.
>
>Badreddine
_______________________________________________
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

Leaf Li

The pinned connection

Reply Threaded

In reply to this post by 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

_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

Haris Kurtagic

RE: The pinned connection

Reply Threaded

I don't think we confused transaction with what is called pinned connection.
I think unnecessary confusion and limitations are in application when pinned
connection is hidden (assumed) to application as it is suggested in RFC.

My suggestion is that developer can acquire FDO connection and then use that
connection in ExecuteSql... functions. In that way developer have clear
picture what is he doing with which FDO connection and can execute any
combination of operations.

Reason why I am mentioning RFC78 is because same solution ( but only for
transactions ) was introduced in the RFC and I think we should combine those
and make one solution to satisfy all needs.

Haris

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Leaf Li
Sent: Tuesday, October 20, 2009 11:46
To: [hidden email]
Subject: [mapguide-internals] The pinned connection

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

Badreddine Karoui

RE: The pinned connection

Reply Threaded

I'm not sure what is the difference between using the proposed fdo connection and using the existing feature source id. It seems that introducing the new connection will require more changes to the API since all the existing commands use feature source id. If the proposed connection will replace the feature source id, then that may not be acceptable since that means clients will be pinning all connections. If this is an addition to the API where both feature source id and connection will be used, then this is cumbersome. I think pinning a connection is an exception/edge case that should not be used unless it's absolutely necessary. As a result an explicit API as suggested by the RFC is appropriate in this case.

Badreddine

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Haris Kurtagic
Sent: Tuesday, October 20, 2009 7:08 AM
To: 'MapGuide Internals Mail List'
Subject: RE: [mapguide-internals] The pinned connection

I don't think we confused transaction with what is called pinned connection.
I think unnecessary confusion and limitations are in application when pinned
connection is hidden (assumed) to application as it is suggested in RFC.

My suggestion is that developer can acquire FDO connection and then use that
connection in ExecuteSql... functions. In that way developer have clear
picture what is he doing with which FDO connection and can execute any
combination of operations.

Reason why I am mentioning RFC78 is because same solution ( but only for
transactions ) was introduced in the RFC and I think we should combine those
and make one solution to satisfy all needs.

Haris

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Leaf Li
Sent: Tuesday, October 20, 2009 11:46
To: [hidden email]
Subject: [mapguide-internals] The pinned connection

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

Haris Kurtagic

RE: The pinned connection

Reply Threaded

Difference is that using feature source id introduce problems we have now
and which we are trying to solve. And problem is as stated in RFC that
developer doesn't have control over which database connection is used when
he wants to execute commands.
If instead of feature source id, parameter would be connection then we
wouldn't have this issues and RFC.

Equivalent changes to API are already suggested in transaction RFC78. So
changes shouldn't be so difficult.
Just instead of transaction as suggested in that RFC we could use connection
as parameter.

I understand that making such changes will change existing API, I would much
reader introduce new clear API then changing existing one to support one
particular case and create existing API more difficult to understand and
use.

This is how I believe API should look like:

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)

Haris

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Badreddine
Karoui
Sent: Tuesday, October 20, 2009 15:30
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] The pinned connection

I'm not sure what is the difference between using the proposed fdo
connection and using the existing feature source id. It seems that
introducing the new connection will require more changes to the API since
all the existing commands use feature source id. If the proposed connection
will replace the feature source id, then that may not be acceptable since
that means clients will be pinning all connections. If this is an addition
to the API where both feature source id and connection will be used, then
this is cumbersome. I think pinning a connection is an exception/edge case
that should not be used unless it's absolutely necessary. As a result an
explicit API as suggested by the RFC is appropriate in this case.

Badreddine

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Haris
Kurtagic
Sent: Tuesday, October 20, 2009 7:08 AM
To: 'MapGuide Internals Mail List'
Subject: RE: [mapguide-internals] The pinned connection

I don't think we confused transaction with what is called pinned connection.
I think unnecessary confusion and limitations are in application when pinned
connection is hidden (assumed) to application as it is suggested in RFC.

My suggestion is that developer can acquire FDO connection and then use that
connection in ExecuteSql... functions. In that way developer have clear
picture what is he doing with which FDO connection and can execute any
combination of operations.

Reason why I am mentioning RFC78 is because same solution ( but only for
transactions ) was introduced in the RFC and I think we should combine those
and make one solution to satisfy all needs.

Haris

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Leaf Li
Sent: Tuesday, October 20, 2009 11:46
To: [hidden email]
Subject: [mapguide-internals] The pinned connection

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

Badreddine Karoui

RE: The pinned connection

Reply Threaded

In the web environment not having control over which connection to use is NOT a problem; It's a feature. The connection pooling/sharing is a scalability feature. However, that can be an issue/restriction for some special/edge and uncommon cases. For those cases, we have a special solution that can be used; temporary pin the connection. BTW. This is similar to pinning a .Net managed object when a unmanaged object need to keep a reference to the managed object.

Badreddine

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Haris Kurtagic
Sent: Tuesday, October 20, 2009 10:11 AM
To: 'MapGuide Internals Mail List'
Subject: RE: [mapguide-internals] The pinned connection

Difference is that using feature source id introduce problems we have now
and which we are trying to solve. And problem is as stated in RFC that
developer doesn't have control over which database connection is used when
he wants to execute commands.
If instead of feature source id, parameter would be connection then we
wouldn't have this issues and RFC.

Equivalent changes to API are already suggested in transaction RFC78. So
changes shouldn't be so difficult.
Just instead of transaction as suggested in that RFC we could use connection
as parameter.

I understand that making such changes will change existing API, I would much
reader introduce new clear API then changing existing one to support one
particular case and create existing API more difficult to understand and
use.

This is how I believe API should look like:

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)

Haris

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Badreddine
Karoui
Sent: Tuesday, October 20, 2009 15:30
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] The pinned connection

I'm not sure what is the difference between using the proposed fdo
connection and using the existing feature source id. It seems that
introducing the new connection will require more changes to the API since
all the existing commands use feature source id. If the proposed connection
will replace the feature source id, then that may not be acceptable since
that means clients will be pinning all connections. If this is an addition
to the API where both feature source id and connection will be used, then
this is cumbersome. I think pinning a connection is an exception/edge case
that should not be used unless it's absolutely necessary. As a result an
explicit API as suggested by the RFC is appropriate in this case.

Badreddine

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Haris
Kurtagic
Sent: Tuesday, October 20, 2009 7:08 AM
To: 'MapGuide Internals Mail List'
Subject: RE: [mapguide-internals] The pinned connection

I don't think we confused transaction with what is called pinned connection.
I think unnecessary confusion and limitations are in application when pinned
connection is hidden (assumed) to application as it is suggested in RFC.

My suggestion is that developer can acquire FDO connection and then use that
connection in ExecuteSql... functions. In that way developer have clear
picture what is he doing with which FDO connection and can execute any
combination of operations.

Reason why I am mentioning RFC78 is because same solution ( but only for
transactions ) was introduced in the RFC and I think we should combine those
and make one solution to satisfy all needs.

Haris

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Leaf Li
Sent: Tuesday, October 20, 2009 11:46
To: [hidden email]
Subject: [mapguide-internals] The pinned connection

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

UV-2

Re: The pinned connection

Reply Threaded

The discussion is now getting the right direction.
It looks like we have a hierarchical relationship between dedicated
connection and transaction context.

I like the example from Haris below. We need more like this!

We should consider all those use cases before the right decision can be
made.
In particular the various multi user scenarios can be quite different.
I think it is rather important for such parts of the design to be very
clear about the range of use cases involved.

E.g. on our server we are serving a huge map but read only.
I am sure this is a common but not the most complex user scenarios.

1. we have to make sure not to break the functionality in existing
applications.
2. And we need to design this part of the system to be able to scale it up.

I am think the feature reader is one of the major bottleneck of this
server so lets try to be very smart about this.
Scalability will become increasingly important in particular with cloud
deployment in mind.

Badreddine Karoui wrote:

> In the web environment not having control over which connection to use is NOT a problem; It's a feature. The connection pooling/sharing is a scalability feature. However, that can be an issue/restriction for some special/edge and uncommon cases. For those cases, we have a special solution that can be used; temporary pin the connection. BTW. This is similar to pinning a .Net managed object when a unmanaged object need to keep a reference to the managed object.
>
> Badreddine
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of Haris Kurtagic
> Sent: Tuesday, October 20, 2009 10:11 AM
> To: 'MapGuide Internals Mail List'
> Subject: RE: [mapguide-internals] The pinned connection
>
> Difference is that using feature source id introduce problems we have now
> and which we are trying to solve. And problem is as stated in RFC that
> developer doesn't have control over which database connection is used when
> he wants to execute commands.
> If instead of feature source id, parameter would be connection then we
> wouldn't have this issues and RFC.
>
> Equivalent changes to API are already suggested in transaction RFC78. So
> changes shouldn't be so difficult.
> Just instead of transaction as suggested in that RFC we could use connection
> as parameter.
>
> I understand that making such changes will change existing API, I would much
> reader introduce new clear API then changing existing one to support one
> particular case and create existing API more difficult to understand and
> use.
>
>
> This is how I believe API should look like:
>
> 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)
>
>
> Haris
>
>
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Badreddine
> Karoui
> Sent: Tuesday, October 20, 2009 15:30
> To: MapGuide Internals Mail List
> Subject: RE: [mapguide-internals] The pinned connection
>
> I'm not sure what is the difference between using the proposed fdo
> connection and using the existing feature source id. It seems that
> introducing the new connection will require more changes to the API since
> all the existing commands use feature source id. If the proposed connection
> will replace the feature source id, then that may not be acceptable since
> that means clients will be pinning all connections. If this is an addition
> to the API where both feature source id and connection will be used, then
> this is cumbersome. I think pinning a connection is an exception/edge case
> that should not be used unless it's absolutely necessary. As a result an
> explicit API as suggested by the RFC is appropriate in this case.
>
> Badreddine
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Haris
> Kurtagic
> Sent: Tuesday, October 20, 2009 7:08 AM
> To: 'MapGuide Internals Mail List'
> Subject: RE: [mapguide-internals] The pinned connection
>
> I don't think we confused transaction with what is called pinned connection.
> I think unnecessary confusion and limitations are in application when pinned
> connection is hidden (assumed) to application as it is suggested in RFC.
>
> My suggestion is that developer can acquire FDO connection and then use that
> connection in ExecuteSql... functions. In that way developer have clear
> picture what is he doing with which FDO connection and can execute any
> combination of operations.
>
> Reason why I am mentioning RFC78 is because same solution ( but only for
> transactions ) was introduced in the RFC and I think we should combine those
> and make one solution to satisfy all needs.
>
> Haris
>
>
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Leaf Li
> Sent: Tuesday, October 20, 2009 11:46
> To: [hidden email]
> Subject: [mapguide-internals] The pinned connection
>
> 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
>>
>
> _______________________________________________
> 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
> _______________________________________________
> 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

Haris Kurtagic

RE: The pinned connection

Reply Threaded

In reply to this post by Badreddine Karoui

Hm, that is not true. Obviously it is a problem otherwise we wouldn't have
this RFC.
Connection pooling stays and it is common in web development but have
nothing to do with this discussion and RFC. Regarding connection pooling
nothing changes

I understand what you want to do, I am suggesting to instead of just pin one
connection and then assume in all other executions that user wanted to use
that only pinned connection, return that connection ( in a way of new class
or id or ... ) and then allow connections to be used in commands.

Haris

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Badreddine
Karoui
Sent: Tuesday, October 20, 2009 16:28
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] The pinned connection

In the web environment not having control over which connection to use is
NOT a problem; It's a feature. The connection pooling/sharing is a
scalability feature. However, that can be an issue/restriction for some
special/edge and uncommon cases. For those cases, we have a special solution
that can be used; temporary pin the connection. BTW. This is similar to
pinning a .Net managed object when a unmanaged object need to keep a
reference to the managed object.

Badreddine

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Haris
Kurtagic
Sent: Tuesday, October 20, 2009 10:11 AM
To: 'MapGuide Internals Mail List'
Subject: RE: [mapguide-internals] The pinned connection

Difference is that using feature source id introduce problems we have now
and which we are trying to solve. And problem is as stated in RFC that
developer doesn't have control over which database connection is used when
he wants to execute commands.
If instead of feature source id, parameter would be connection then we
wouldn't have this issues and RFC.

Equivalent changes to API are already suggested in transaction RFC78. So
changes shouldn't be so difficult.
Just instead of transaction as suggested in that RFC we could use connection
as parameter.

I understand that making such changes will change existing API, I would much
reader introduce new clear API then changing existing one to support one
particular case and create existing API more difficult to understand and
use.

This is how I believe API should look like:

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)

Haris

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Badreddine
Karoui
Sent: Tuesday, October 20, 2009 15:30
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] The pinned connection

I'm not sure what is the difference between using the proposed fdo
connection and using the existing feature source id. It seems that
introducing the new connection will require more changes to the API since
all the existing commands use feature source id. If the proposed connection
will replace the feature source id, then that may not be acceptable since
that means clients will be pinning all connections. If this is an addition
to the API where both feature source id and connection will be used, then
this is cumbersome. I think pinning a connection is an exception/edge case
that should not be used unless it's absolutely necessary. As a result an
explicit API as suggested by the RFC is appropriate in this case.

Badreddine

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Haris
Kurtagic
Sent: Tuesday, October 20, 2009 7:08 AM
To: 'MapGuide Internals Mail List'
Subject: RE: [mapguide-internals] The pinned connection

I don't think we confused transaction with what is called pinned connection.
I think unnecessary confusion and limitations are in application when pinned
connection is hidden (assumed) to application as it is suggested in RFC.

My suggestion is that developer can acquire FDO connection and then use that
connection in ExecuteSql... functions. In that way developer have clear
picture what is he doing with which FDO connection and can execute any
combination of operations.

Reason why I am mentioning RFC78 is because same solution ( but only for
transactions ) was introduced in the RFC and I think we should combine those
and make one solution to satisfy all needs.

Haris

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Leaf Li
Sent: Tuesday, October 20, 2009 11:46
To: [hidden email]
Subject: [mapguide-internals] The pinned connection

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

Badreddine Karoui

RE: The pinned connection

Reply Threaded

I don't think there is anything assumed about what connection is pinned. If a PinConnection is called using a specific feature source id, then all the calls using that feature source id will use the pinned connection associated with that fsid. There is no assumption made, the use of the pinned connection is explicit through the use of the feature source id.

Badreddine

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Haris Kurtagic
Sent: Tuesday, October 20, 2009 12:57 PM
To: 'MapGuide Internals Mail List'
Subject: RE: [mapguide-internals] The pinned connection

Hm, that is not true. Obviously it is a problem otherwise we wouldn't have
this RFC.
Connection pooling stays and it is common in web development but have
nothing to do with this discussion and RFC. Regarding connection pooling
nothing changes

I understand what you want to do, I am suggesting to instead of just pin one
connection and then assume in all other executions that user wanted to use
that only pinned connection, return that connection ( in a way of new class
or id or ... ) and then allow connections to be used in commands.

Haris

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Badreddine
Karoui
Sent: Tuesday, October 20, 2009 16:28
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] The pinned connection

In the web environment not having control over which connection to use is
NOT a problem; It's a feature. The connection pooling/sharing is a
scalability feature. However, that can be an issue/restriction for some
special/edge and uncommon cases. For those cases, we have a special solution
that can be used; temporary pin the connection. BTW. This is similar to
pinning a .Net managed object when a unmanaged object need to keep a
reference to the managed object.

Badreddine

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Haris
Kurtagic
Sent: Tuesday, October 20, 2009 10:11 AM
To: 'MapGuide Internals Mail List'
Subject: RE: [mapguide-internals] The pinned connection

Difference is that using feature source id introduce problems we have now
and which we are trying to solve. And problem is as stated in RFC that
developer doesn't have control over which database connection is used when
he wants to execute commands.
If instead of feature source id, parameter would be connection then we
wouldn't have this issues and RFC.

Equivalent changes to API are already suggested in transaction RFC78. So
changes shouldn't be so difficult.
Just instead of transaction as suggested in that RFC we could use connection
as parameter.

I understand that making such changes will change existing API, I would much
reader introduce new clear API then changing existing one to support one
particular case and create existing API more difficult to understand and
use.

This is how I believe API should look like:

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)

Haris

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Badreddine
Karoui
Sent: Tuesday, October 20, 2009 15:30
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] The pinned connection

I'm not sure what is the difference between using the proposed fdo
connection and using the existing feature source id. It seems that
introducing the new connection will require more changes to the API since
all the existing commands use feature source id. If the proposed connection
will replace the feature source id, then that may not be acceptable since
that means clients will be pinning all connections. If this is an addition
to the API where both feature source id and connection will be used, then
this is cumbersome. I think pinning a connection is an exception/edge case
that should not be used unless it's absolutely necessary. As a result an
explicit API as suggested by the RFC is appropriate in this case.

Badreddine

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Haris
Kurtagic
Sent: Tuesday, October 20, 2009 7:08 AM
To: 'MapGuide Internals Mail List'
Subject: RE: [mapguide-internals] The pinned connection

I don't think we confused transaction with what is called pinned connection.
I think unnecessary confusion and limitations are in application when pinned
connection is hidden (assumed) to application as it is suggested in RFC.

My suggestion is that developer can acquire FDO connection and then use that
connection in ExecuteSql... functions. In that way developer have clear
picture what is he doing with which FDO connection and can execute any
combination of operations.

Reason why I am mentioning RFC78 is because same solution ( but only for
transactions ) was introduced in the RFC and I think we should combine those
and make one solution to satisfy all needs.

Haris

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Leaf Li
Sent: Tuesday, October 20, 2009 11:46
To: [hidden email]
Subject: [mapguide-internals] The pinned connection

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

Haris Kurtagic

RE: The pinned connection

Reply Threaded

Yes, and one of issues of RFC is that you can't have another one

Haris

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Badreddine
Karoui
Sent: Tuesday, October 20, 2009 19:11
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] The pinned connection

I don't think there is anything assumed about what connection is pinned. If
a PinConnection is called using a specific feature source id, then all the
calls using that feature source id will use the pinned connection associated
with that fsid. There is no assumption made, the use of the pinned
connection is explicit through the use of the feature source id.

Badreddine

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Haris
Kurtagic
Sent: Tuesday, October 20, 2009 12:57 PM
To: 'MapGuide Internals Mail List'
Subject: RE: [mapguide-internals] The pinned connection

Hm, that is not true. Obviously it is a problem otherwise we wouldn't have
this RFC.
Connection pooling stays and it is common in web development but have
nothing to do with this discussion and RFC. Regarding connection pooling
nothing changes

I understand what you want to do, I am suggesting to instead of just pin one
connection and then assume in all other executions that user wanted to use
that only pinned connection, return that connection ( in a way of new class
or id or ... ) and then allow connections to be used in commands.

Haris

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Badreddine
Karoui
Sent: Tuesday, October 20, 2009 16:28
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] The pinned connection

In the web environment not having control over which connection to use is
NOT a problem; It's a feature. The connection pooling/sharing is a
scalability feature. However, that can be an issue/restriction for some
special/edge and uncommon cases. For those cases, we have a special solution
that can be used; temporary pin the connection. BTW. This is similar to
pinning a .Net managed object when a unmanaged object need to keep a
reference to the managed object.

Badreddine

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Haris
Kurtagic
Sent: Tuesday, October 20, 2009 10:11 AM
To: 'MapGuide Internals Mail List'
Subject: RE: [mapguide-internals] The pinned connection

Difference is that using feature source id introduce problems we have now
and which we are trying to solve. And problem is as stated in RFC that
developer doesn't have control over which database connection is used when
he wants to execute commands.
If instead of feature source id, parameter would be connection then we
wouldn't have this issues and RFC.

Equivalent changes to API are already suggested in transaction RFC78. So
changes shouldn't be so difficult.
Just instead of transaction as suggested in that RFC we could use connection
as parameter.

I understand that making such changes will change existing API, I would much
reader introduce new clear API then changing existing one to support one
particular case and create existing API more difficult to understand and
use.

This is how I believe API should look like:

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)

Haris

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Badreddine
Karoui
Sent: Tuesday, October 20, 2009 15:30
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] The pinned connection

I'm not sure what is the difference between using the proposed fdo
connection and using the existing feature source id. It seems that
introducing the new connection will require more changes to the API since
all the existing commands use feature source id. If the proposed connection
will replace the feature source id, then that may not be acceptable since
that means clients will be pinning all connections. If this is an addition
to the API where both feature source id and connection will be used, then
this is cumbersome. I think pinning a connection is an exception/edge case
that should not be used unless it's absolutely necessary. As a result an
explicit API as suggested by the RFC is appropriate in this case.

Badreddine

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Haris
Kurtagic
Sent: Tuesday, October 20, 2009 7:08 AM
To: 'MapGuide Internals Mail List'
Subject: RE: [mapguide-internals] The pinned connection

I don't think we confused transaction with what is called pinned connection.
I think unnecessary confusion and limitations are in application when pinned
connection is hidden (assumed) to application as it is suggested in RFC.

My suggestion is that developer can acquire FDO connection and then use that
connection in ExecuteSql... functions. In that way developer have clear
picture what is he doing with which FDO connection and can execute any
combination of operations.

Reason why I am mentioning RFC78 is because same solution ( but only for
transactions ) was introduced in the RFC and I think we should combine those
and make one solution to satisfy all needs.

Haris

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Leaf Li
Sent: Tuesday, October 20, 2009 11:46
To: [hidden email]
Subject: [mapguide-internals] The pinned connection

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

Badreddine Karoui

RE: The pinned connection

Reply Threaded

Why not? I just create 2 FSIDs and pinned them both. An application should be able to use any number of unique FSIDs.

Badreddine

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Haris Kurtagic
Sent: Tuesday, October 20, 2009 1:24 PM
To: 'MapGuide Internals Mail List'
Subject: RE: [mapguide-internals] The pinned connection

Yes, and one of issues of RFC is that you can't have another one

Haris

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Badreddine
Karoui
Sent: Tuesday, October 20, 2009 19:11
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] The pinned connection

I don't think there is anything assumed about what connection is pinned. If
a PinConnection is called using a specific feature source id, then all the
calls using that feature source id will use the pinned connection associated
with that fsid. There is no assumption made, the use of the pinned
connection is explicit through the use of the feature source id.

Badreddine

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Haris
Kurtagic
Sent: Tuesday, October 20, 2009 12:57 PM
To: 'MapGuide Internals Mail List'
Subject: RE: [mapguide-internals] The pinned connection

Hm, that is not true. Obviously it is a problem otherwise we wouldn't have
this RFC.
Connection pooling stays and it is common in web development but have
nothing to do with this discussion and RFC. Regarding connection pooling
nothing changes

I understand what you want to do, I am suggesting to instead of just pin one
connection and then assume in all other executions that user wanted to use
that only pinned connection, return that connection ( in a way of new class
or id or ... ) and then allow connections to be used in commands.

Haris

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Badreddine
Karoui
Sent: Tuesday, October 20, 2009 16:28
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] The pinned connection

In the web environment not having control over which connection to use is
NOT a problem; It's a feature. The connection pooling/sharing is a
scalability feature. However, that can be an issue/restriction for some
special/edge and uncommon cases. For those cases, we have a special solution
that can be used; temporary pin the connection. BTW. This is similar to
pinning a .Net managed object when a unmanaged object need to keep a
reference to the managed object.

Badreddine

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Haris
Kurtagic
Sent: Tuesday, October 20, 2009 10:11 AM
To: 'MapGuide Internals Mail List'
Subject: RE: [mapguide-internals] The pinned connection

Difference is that using feature source id introduce problems we have now
and which we are trying to solve. And problem is as stated in RFC that
developer doesn't have control over which database connection is used when
he wants to execute commands.
If instead of feature source id, parameter would be connection then we
wouldn't have this issues and RFC.

Equivalent changes to API are already suggested in transaction RFC78. So
changes shouldn't be so difficult.
Just instead of transaction as suggested in that RFC we could use connection
as parameter.

I understand that making such changes will change existing API, I would much
reader introduce new clear API then changing existing one to support one
particular case and create existing API more difficult to understand and
use.

This is how I believe API should look like:

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)

Haris

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Badreddine
Karoui
Sent: Tuesday, October 20, 2009 15:30
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] The pinned connection

I'm not sure what is the difference between using the proposed fdo
connection and using the existing feature source id. It seems that
introducing the new connection will require more changes to the API since
all the existing commands use feature source id. If the proposed connection
will replace the feature source id, then that may not be acceptable since
that means clients will be pinning all connections. If this is an addition
to the API where both feature source id and connection will be used, then
this is cumbersome. I think pinning a connection is an exception/edge case
that should not be used unless it's absolutely necessary. As a result an
explicit API as suggested by the RFC is appropriate in this case.

Badreddine

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Haris
Kurtagic
Sent: Tuesday, October 20, 2009 7:08 AM
To: 'MapGuide Internals Mail List'
Subject: RE: [mapguide-internals] The pinned connection

I don't think we confused transaction with what is called pinned connection.
I think unnecessary confusion and limitations are in application when pinned
connection is hidden (assumed) to application as it is suggested in RFC.

My suggestion is that developer can acquire FDO connection and then use that
connection in ExecuteSql... functions. In that way developer have clear
picture what is he doing with which FDO connection and can execute any
combination of operations.

Reason why I am mentioning RFC78 is because same solution ( but only for
transactions ) was introduced in the RFC and I think we should combine those
and make one solution to satisfy all needs.

Haris

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Leaf Li
Sent: Tuesday, October 20, 2009 11:46
To: [hidden email]
Subject: [mapguide-internals] The pinned connection

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

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

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

Haris Kurtagic

RE: The pinned connection

Reply Threaded

?? Now you are getting me confused :)

Isn't proposed solution in RFC "PinConnection(MgResourceIdentifier
featureSourceId)" referring to Feature Source which identifies particular
Feature Source and it is one unique id for one feature source ?

Haris

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Badreddine
Karoui
Sent: Tuesday, October 20, 2009 19:29
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] The pinned connection

Why not? I just create 2 FSIDs and pinned them both. An application should
be able to use any number of unique FSIDs.

Badreddine

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Haris
Kurtagic
Sent: Tuesday, October 20, 2009 1:24 PM
To: 'MapGuide Internals Mail List'
Subject: RE: [mapguide-internals] The pinned connection

Yes, and one of issues of RFC is that you can't have another one

Haris

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Badreddine
Karoui
Sent: Tuesday, October 20, 2009 19:11
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] The pinned connection

I don't think there is anything assumed about what connection is pinned. If
a PinConnection is called using a specific feature source id, then all the
calls using that feature source id will use the pinned connection associated
with that fsid. There is no assumption made, the use of the pinned
connection is explicit through the use of the feature source id.

Badreddine

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Haris
Kurtagic
Sent: Tuesday, October 20, 2009 12:57 PM
To: 'MapGuide Internals Mail List'
Subject: RE: [mapguide-internals] The pinned connection

Hm, that is not true. Obviously it is a problem otherwise we wouldn't have
this RFC.
Connection pooling stays and it is common in web development but have
nothing to do with this discussion and RFC. Regarding connection pooling
nothing changes

I understand what you want to do, I am suggesting to instead of just pin one
connection and then assume in all other executions that user wanted to use
that only pinned connection, return that connection ( in a way of new class
or id or ... ) and then allow connections to be used in commands.

Haris

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Badreddine
Karoui
Sent: Tuesday, October 20, 2009 16:28
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] The pinned connection

In the web environment not having control over which connection to use is
NOT a problem; It's a feature. The connection pooling/sharing is a
scalability feature. However, that can be an issue/restriction for some
special/edge and uncommon cases. For those cases, we have a special solution
that can be used; temporary pin the connection. BTW. This is similar to
pinning a .Net managed object when a unmanaged object need to keep a
reference to the managed object.

Badreddine

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Haris
Kurtagic
Sent: Tuesday, October 20, 2009 10:11 AM
To: 'MapGuide Internals Mail List'
Subject: RE: [mapguide-internals] The pinned connection

Difference is that using feature source id introduce problems we have now
and which we are trying to solve. And problem is as stated in RFC that
developer doesn't have control over which database connection is used when
he wants to execute commands.
If instead of feature source id, parameter would be connection then we
wouldn't have this issues and RFC.

Equivalent changes to API are already suggested in transaction RFC78. So
changes shouldn't be so difficult.
Just instead of transaction as suggested in that RFC we could use connection
as parameter.

I understand that making such changes will change existing API, I would much
reader introduce new clear API then changing existing one to support one
particular case and create existing API more difficult to understand and
use.

This is how I believe API should look like:

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)

Haris

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Badreddine
Karoui
Sent: Tuesday, October 20, 2009 15:30
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] The pinned connection

I'm not sure what is the difference between using the proposed fdo
connection and using the existing feature source id. It seems that
introducing the new connection will require more changes to the API since
all the existing commands use feature source id. If the proposed connection
will replace the feature source id, then that may not be acceptable since
that means clients will be pinning all connections. If this is an addition
to the API where both feature source id and connection will be used, then
this is cumbersome. I think pinning a connection is an exception/edge case
that should not be used unless it's absolutely necessary. As a result an
explicit API as suggested by the RFC is appropriate in this case.

Badreddine

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Haris
Kurtagic
Sent: Tuesday, October 20, 2009 7:08 AM
To: 'MapGuide Internals Mail List'
Subject: RE: [mapguide-internals] The pinned connection

I don't think we confused transaction with what is called pinned connection.
I think unnecessary confusion and limitations are in application when pinned
connection is hidden (assumed) to application as it is suggested in RFC.

My suggestion is that developer can acquire FDO connection and then use that
connection in ExecuteSql... functions. In that way developer have clear
picture what is he doing with which FDO connection and can execute any
combination of operations.

Reason why I am mentioning RFC78 is because same solution ( but only for
transactions ) was introduced in the RFC and I think we should combine those
and make one solution to satisfy all needs.

Haris

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Leaf Li
Sent: Tuesday, October 20, 2009 11:46
To: [hidden email]
Subject: [mapguide-internals] The pinned connection

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

Badreddine Karoui

RE: The pinned connection

Reply Threaded

You mean I cannot create multiple feature source IDs to the same data? That sounds like a deployment issue; if an application requires the use of a pinned connection and a regular connection at the same time, then I would provision 2 feature source ids to the same datastore. Or may be I don't understand that part?

Badreddine

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Haris Kurtagic
Sent: Tuesday, October 20, 2009 1:34 PM
To: 'MapGuide Internals Mail List'
Subject: RE: [mapguide-internals] The pinned connection

?? Now you are getting me confused :)

Isn't proposed solution in RFC "PinConnection(MgResourceIdentifier
featureSourceId)" referring to Feature Source which identifies particular
Feature Source and it is one unique id for one feature source ?

Haris

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Badreddine
Karoui
Sent: Tuesday, October 20, 2009 19:29
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] The pinned connection

Why not? I just create 2 FSIDs and pinned them both. An application should
be able to use any number of unique FSIDs.

Badreddine

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Haris
Kurtagic
Sent: Tuesday, October 20, 2009 1:24 PM
To: 'MapGuide Internals Mail List'
Subject: RE: [mapguide-internals] The pinned connection

Yes, and one of issues of RFC is that you can't have another one

Haris

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Badreddine
Karoui
Sent: Tuesday, October 20, 2009 19:11
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] The pinned connection

I don't think there is anything assumed about what connection is pinned. If
a PinConnection is called using a specific feature source id, then all the
calls using that feature source id will use the pinned connection associated
with that fsid. There is no assumption made, the use of the pinned
connection is explicit through the use of the feature source id.

Badreddine

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Haris
Kurtagic
Sent: Tuesday, October 20, 2009 12:57 PM
To: 'MapGuide Internals Mail List'
Subject: RE: [mapguide-internals] The pinned connection

Hm, that is not true. Obviously it is a problem otherwise we wouldn't have
this RFC.
Connection pooling stays and it is common in web development but have
nothing to do with this discussion and RFC. Regarding connection pooling
nothing changes

I understand what you want to do, I am suggesting to instead of just pin one
connection and then assume in all other executions that user wanted to use
that only pinned connection, return that connection ( in a way of new class
or id or ... ) and then allow connections to be used in commands.

Haris

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Badreddine
Karoui
Sent: Tuesday, October 20, 2009 16:28
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] The pinned connection

In the web environment not having control over which connection to use is
NOT a problem; It's a feature. The connection pooling/sharing is a
scalability feature. However, that can be an issue/restriction for some
special/edge and uncommon cases. For those cases, we have a special solution
that can be used; temporary pin the connection. BTW. This is similar to
pinning a .Net managed object when a unmanaged object need to keep a
reference to the managed object.

Badreddine

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Haris
Kurtagic
Sent: Tuesday, October 20, 2009 10:11 AM
To: 'MapGuide Internals Mail List'
Subject: RE: [mapguide-internals] The pinned connection

Difference is that using feature source id introduce problems we have now
and which we are trying to solve. And problem is as stated in RFC that
developer doesn't have control over which database connection is used when
he wants to execute commands.
If instead of feature source id, parameter would be connection then we
wouldn't have this issues and RFC.

Equivalent changes to API are already suggested in transaction RFC78. So
changes shouldn't be so difficult.
Just instead of transaction as suggested in that RFC we could use connection
as parameter.

I understand that making such changes will change existing API, I would much
reader introduce new clear API then changing existing one to support one
particular case and create existing API more difficult to understand and
use.

This is how I believe API should look like:

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)

Haris

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Badreddine
Karoui
Sent: Tuesday, October 20, 2009 15:30
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] The pinned connection

I'm not sure what is the difference between using the proposed fdo
connection and using the existing feature source id. It seems that
introducing the new connection will require more changes to the API since
all the existing commands use feature source id. If the proposed connection
will replace the feature source id, then that may not be acceptable since
that means clients will be pinning all connections. If this is an addition
to the API where both feature source id and connection will be used, then
this is cumbersome. I think pinning a connection is an exception/edge case
that should not be used unless it's absolutely necessary. As a result an
explicit API as suggested by the RFC is appropriate in this case.

Badreddine

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Haris
Kurtagic
Sent: Tuesday, October 20, 2009 7:08 AM
To: 'MapGuide Internals Mail List'
Subject: RE: [mapguide-internals] The pinned connection

I don't think we confused transaction with what is called pinned connection.
I think unnecessary confusion and limitations are in application when pinned
connection is hidden (assumed) to application as it is suggested in RFC.

My suggestion is that developer can acquire FDO connection and then use that
connection in ExecuteSql... functions. In that way developer have clear
picture what is he doing with which FDO connection and can execute any
combination of operations.

Reason why I am mentioning RFC78 is because same solution ( but only for
transactions ) was introduced in the RFC and I think we should combine those
and make one solution to satisfy all needs.

Haris

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Leaf Li
Sent: Tuesday, October 20, 2009 11:46
To: [hidden email]
Subject: [mapguide-internals] The pinned connection

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

Traian Stanev

RE: The pinned connection

Reply Threaded

It's rather sub-optimal from usability perspective to have to copy a feature source only so that you can pin a connection to it, when it should be possible and not much harder to write code that can pin a number of connections to the same feature source.

Traian

> -----Original Message-----
> From: [hidden email] [mailto:mapguide-internals-
> [hidden email]] On Behalf Of Badreddine Karoui
> Sent: Tuesday, October 20, 2009 1:41 PM
> To: MapGuide Internals Mail List
> Subject: RE: [mapguide-internals] The pinned connection
>
> You mean I cannot create multiple feature source IDs to the same data? That
> sounds like a deployment issue; if an application requires the use of a
> pinned connection and a regular connection at the same time, then I would
> provision 2 feature source ids to the same datastore. Or may be I don't
> understand that part?
>
> Badreddine
>
> -----Original Message-----
> From: [hidden email] [mailto:mapguide-internals-
> [hidden email]] On Behalf Of Haris Kurtagic
> Sent: Tuesday, October 20, 2009 1:34 PM
> To: 'MapGuide Internals Mail List'
> Subject: RE: [mapguide-internals] The pinned connection
>
> ?? Now you are getting me confused :)
>
> Isn't proposed solution in RFC "PinConnection(MgResourceIdentifier
> featureSourceId)" referring to Feature Source which identifies particular
> Feature Source and it is one unique id for one feature source ?
>
> Haris
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Badreddine
> Karoui
> Sent: Tuesday, October 20, 2009 19:29
> To: MapGuide Internals Mail List
> Subject: RE: [mapguide-internals] The pinned connection
>
> Why not? I just create 2 FSIDs and pinned them both. An application should
> be able to use any number of unique FSIDs.
>
> Badreddine
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Haris
> Kurtagic
> Sent: Tuesday, October 20, 2009 1:24 PM
> To: 'MapGuide Internals Mail List'
> Subject: RE: [mapguide-internals] The pinned connection
>
> Yes, and one of issues of RFC is that you can't have another one
>
> Haris
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Badreddine
> Karoui
> Sent: Tuesday, October 20, 2009 19:11
> To: MapGuide Internals Mail List
> Subject: RE: [mapguide-internals] The pinned connection
>
> I don't think there is anything assumed about what connection is pinned. If
> a PinConnection is called using a specific feature source id, then all the
> calls using that feature source id will use the pinned connection associated
> with that fsid. There is no assumption made, the use of the pinned
> connection is explicit through the use of the feature source id.
>
> Badreddine
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Haris
> Kurtagic
> Sent: Tuesday, October 20, 2009 12:57 PM
> To: 'MapGuide Internals Mail List'
> Subject: RE: [mapguide-internals] The pinned connection
>
> Hm, that is not true. Obviously it is a problem otherwise we wouldn't have
> this RFC.
> Connection pooling stays and it is common in web development but have
> nothing to do with this discussion and RFC. Regarding connection pooling
> nothing changes
>
> I understand what you want to do, I am suggesting to instead of just pin one
> connection and then assume in all other executions that user wanted to use
> that only pinned connection, return that connection ( in a way of new class
> or id or ... ) and then allow connections to be used in commands.
>
> Haris
>
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Badreddine
> Karoui
> Sent: Tuesday, October 20, 2009 16:28
> To: MapGuide Internals Mail List
> Subject: RE: [mapguide-internals] The pinned connection
>
> In the web environment not having control over which connection to use is
> NOT a problem; It's a feature. The connection pooling/sharing is a
> scalability feature. However, that can be an issue/restriction for some
> special/edge and uncommon cases. For those cases, we have a special solution
> that can be used; temporary pin the connection. BTW. This is similar to
> pinning a .Net managed object when a unmanaged object need to keep a
> reference to the managed object.
>
> Badreddine
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Haris
> Kurtagic
> Sent: Tuesday, October 20, 2009 10:11 AM
> To: 'MapGuide Internals Mail List'
> Subject: RE: [mapguide-internals] The pinned connection
>
> Difference is that using feature source id introduce problems we have now
> and which we are trying to solve. And problem is as stated in RFC that
> developer doesn't have control over which database connection is used when
> he wants to execute commands.
> If instead of feature source id, parameter would be connection then we
> wouldn't have this issues and RFC.
>
> Equivalent changes to API are already suggested in transaction RFC78. So
> changes shouldn't be so difficult.
> Just instead of transaction as suggested in that RFC we could use connection
> as parameter.
>
> I understand that making such changes will change existing API, I would much
> reader introduce new clear API then changing existing one to support one
> particular case and create existing API more difficult to understand and
> use.
>
>
> This is how I believe API should look like:
>
> 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)
>
>
> Haris
>
>
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Badreddine
> Karoui
> Sent: Tuesday, October 20, 2009 15:30
> To: MapGuide Internals Mail List
> Subject: RE: [mapguide-internals] The pinned connection
>
> I'm not sure what is the difference between using the proposed fdo
> connection and using the existing feature source id. It seems that
> introducing the new connection will require more changes to the API since
> all the existing commands use feature source id. If the proposed connection
> will replace the feature source id, then that may not be acceptable since
> that means clients will be pinning all connections. If this is an addition
> to the API where both feature source id and connection will be used, then
> this is cumbersome. I think pinning a connection is an exception/edge case
> that should not be used unless it's absolutely necessary. As a result an
> explicit API as suggested by the RFC is appropriate in this case.
>
> Badreddine
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Haris
> Kurtagic
> Sent: Tuesday, October 20, 2009 7:08 AM
> To: 'MapGuide Internals Mail List'
> Subject: RE: [mapguide-internals] The pinned connection
>
> I don't think we confused transaction with what is called pinned connection.
> I think unnecessary confusion and limitations are in application when pinned
> connection is hidden (assumed) to application as it is suggested in RFC.
>
> My suggestion is that developer can acquire FDO connection and then use that
> connection in ExecuteSql... functions. In that way developer have clear
> picture what is he doing with which FDO connection and can execute any
> combination of operations.
>
> Reason why I am mentioning RFC78 is because same solution ( but only for
> transactions ) was introduced in the RFC and I think we should combine those
> and make one solution to satisfy all needs.
>
> Haris
>
>
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Leaf Li
> Sent: Tuesday, October 20, 2009 11:46
> To: [hidden email]
> Subject: [mapguide-internals] The pinned connection
>
> 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
>
> _______________________________________________
> 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
> _______________________________________________
> 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
> _______________________________________________
> 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

Haris Kurtagic

RE: The pinned connection

Reply Threaded

In reply to this post by Badreddine Karoui

I wouldn't call it deployment issue. The workaround you suggested is
possible but very ugly.

In my opinion API as it is suggested looks very unnatural, has limitations
and is much different than most of standard APIs.

I can guess that primary reason for such suggested solution in RFC was that
changes in existing API are minimal but it makes API looks really strange.

I would much rather see another set of ExecuteSql (e.g. ExecuteSql2 )
commands then trying to combine old and new in such way.

Haris

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Badreddine
Karoui
Sent: Tuesday, October 20, 2009 19:41
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] The pinned connection

You mean I cannot create multiple feature source IDs to the same data? That
sounds like a deployment issue; if an application requires the use of a
pinned connection and a regular connection at the same time, then I would
provision 2 feature source ids to the same datastore. Or may be I don't
understand that part?

Badreddine

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Haris
Kurtagic
Sent: Tuesday, October 20, 2009 1:34 PM
To: 'MapGuide Internals Mail List'
Subject: RE: [mapguide-internals] The pinned connection

?? Now you are getting me confused :)

Isn't proposed solution in RFC "PinConnection(MgResourceIdentifier
featureSourceId)" referring to Feature Source which identifies particular
Feature Source and it is one unique id for one feature source ?

Haris

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Badreddine
Karoui
Sent: Tuesday, October 20, 2009 19:29
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] The pinned connection

Why not? I just create 2 FSIDs and pinned them both. An application should
be able to use any number of unique FSIDs.

Badreddine

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Haris
Kurtagic
Sent: Tuesday, October 20, 2009 1:24 PM
To: 'MapGuide Internals Mail List'
Subject: RE: [mapguide-internals] The pinned connection

Yes, and one of issues of RFC is that you can't have another one

Haris

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Badreddine
Karoui
Sent: Tuesday, October 20, 2009 19:11
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] The pinned connection

I don't think there is anything assumed about what connection is pinned. If
a PinConnection is called using a specific feature source id, then all the
calls using that feature source id will use the pinned connection associated
with that fsid. There is no assumption made, the use of the pinned
connection is explicit through the use of the feature source id.

Badreddine

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Haris
Kurtagic
Sent: Tuesday, October 20, 2009 12:57 PM
To: 'MapGuide Internals Mail List'
Subject: RE: [mapguide-internals] The pinned connection

Hm, that is not true. Obviously it is a problem otherwise we wouldn't have
this RFC.
Connection pooling stays and it is common in web development but have
nothing to do with this discussion and RFC. Regarding connection pooling
nothing changes

I understand what you want to do, I am suggesting to instead of just pin one
connection and then assume in all other executions that user wanted to use
that only pinned connection, return that connection ( in a way of new class
or id or ... ) and then allow connections to be used in commands.

Haris

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Badreddine
Karoui
Sent: Tuesday, October 20, 2009 16:28
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] The pinned connection

In the web environment not having control over which connection to use is
NOT a problem; It's a feature. The connection pooling/sharing is a
scalability feature. However, that can be an issue/restriction for some
special/edge and uncommon cases. For those cases, we have a special solution
that can be used; temporary pin the connection. BTW. This is similar to
pinning a .Net managed object when a unmanaged object need to keep a
reference to the managed object.

Badreddine

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Haris
Kurtagic
Sent: Tuesday, October 20, 2009 10:11 AM
To: 'MapGuide Internals Mail List'
Subject: RE: [mapguide-internals] The pinned connection

Difference is that using feature source id introduce problems we have now
and which we are trying to solve. And problem is as stated in RFC that
developer doesn't have control over which database connection is used when
he wants to execute commands.
If instead of feature source id, parameter would be connection then we
wouldn't have this issues and RFC.

Equivalent changes to API are already suggested in transaction RFC78. So
changes shouldn't be so difficult.
Just instead of transaction as suggested in that RFC we could use connection
as parameter.

I understand that making such changes will change existing API, I would much
reader introduce new clear API then changing existing one to support one
particular case and create existing API more difficult to understand and
use.

This is how I believe API should look like:

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)

Haris

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Badreddine
Karoui
Sent: Tuesday, October 20, 2009 15:30
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] The pinned connection

I'm not sure what is the difference between using the proposed fdo
connection and using the existing feature source id. It seems that
introducing the new connection will require more changes to the API since
all the existing commands use feature source id. If the proposed connection
will replace the feature source id, then that may not be acceptable since
that means clients will be pinning all connections. If this is an addition
to the API where both feature source id and connection will be used, then
this is cumbersome. I think pinning a connection is an exception/edge case
that should not be used unless it's absolutely necessary. As a result an
explicit API as suggested by the RFC is appropriate in this case.

Badreddine

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Haris
Kurtagic
Sent: Tuesday, October 20, 2009 7:08 AM
To: 'MapGuide Internals Mail List'
Subject: RE: [mapguide-internals] The pinned connection

I don't think we confused transaction with what is called pinned connection.
I think unnecessary confusion and limitations are in application when pinned
connection is hidden (assumed) to application as it is suggested in RFC.

My suggestion is that developer can acquire FDO connection and then use that
connection in ExecuteSql... functions. In that way developer have clear
picture what is he doing with which FDO connection and can execute any
combination of operations.

Reason why I am mentioning RFC78 is because same solution ( but only for
transactions ) was introduced in the RFC and I think we should combine those
and make one solution to satisfy all needs.

Haris

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Leaf Li
Sent: Tuesday, October 20, 2009 11:46
To: [hidden email]
Subject: [mapguide-internals] The pinned connection

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

Badreddine Karoui

RE: The pinned connection

Reply Threaded

Again, this is an edge case that should not be used unless it's absolutely necessary. This is needed in conjunction with SQL passthrough and Oracle where the Oracle server may maintain other states/context than transaction state for a given session. In that case the likely use case would be for the application to pin the connection, execute some SQL based operations, unpin the connection and continue with the regular web stateless stuff.
BTW. I always found version 2, Ex, X etc. of existing functions very ugly. I don't think my suggested workaround will be used in this case. But in case an application have a need for such behavior, then it's not locked to the single pinned connection.

Badreddine

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Haris Kurtagic
Sent: Tuesday, October 20, 2009 1:52 PM
To: 'MapGuide Internals Mail List'
Subject: RE: [mapguide-internals] The pinned connection

I wouldn't call it deployment issue. The workaround you suggested is
possible but very ugly.

In my opinion API as it is suggested looks very unnatural, has limitations
and is much different than most of standard APIs.

I can guess that primary reason for such suggested solution in RFC was that
changes in existing API are minimal but it makes API looks really strange.

I would much rather see another set of ExecuteSql (e.g. ExecuteSql2 )
commands then trying to combine old and new in such way.

Haris

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Badreddine
Karoui
Sent: Tuesday, October 20, 2009 19:41
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] The pinned connection

You mean I cannot create multiple feature source IDs to the same data? That
sounds like a deployment issue; if an application requires the use of a
pinned connection and a regular connection at the same time, then I would
provision 2 feature source ids to the same datastore. Or may be I don't
understand that part?

Badreddine

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Haris
Kurtagic
Sent: Tuesday, October 20, 2009 1:34 PM
To: 'MapGuide Internals Mail List'
Subject: RE: [mapguide-internals] The pinned connection

?? Now you are getting me confused :)

Isn't proposed solution in RFC "PinConnection(MgResourceIdentifier
featureSourceId)" referring to Feature Source which identifies particular
Feature Source and it is one unique id for one feature source ?

Haris

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Badreddine
Karoui
Sent: Tuesday, October 20, 2009 19:29
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] The pinned connection

Why not? I just create 2 FSIDs and pinned them both. An application should
be able to use any number of unique FSIDs.

Badreddine

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Haris
Kurtagic
Sent: Tuesday, October 20, 2009 1:24 PM
To: 'MapGuide Internals Mail List'
Subject: RE: [mapguide-internals] The pinned connection

Yes, and one of issues of RFC is that you can't have another one

Haris

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Badreddine
Karoui
Sent: Tuesday, October 20, 2009 19:11
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] The pinned connection

I don't think there is anything assumed about what connection is pinned. If
a PinConnection is called using a specific feature source id, then all the
calls using that feature source id will use the pinned connection associated
with that fsid. There is no assumption made, the use of the pinned
connection is explicit through the use of the feature source id.

Badreddine

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Haris
Kurtagic
Sent: Tuesday, October 20, 2009 12:57 PM
To: 'MapGuide Internals Mail List'
Subject: RE: [mapguide-internals] The pinned connection

Hm, that is not true. Obviously it is a problem otherwise we wouldn't have
this RFC.
Connection pooling stays and it is common in web development but have
nothing to do with this discussion and RFC. Regarding connection pooling
nothing changes

I understand what you want to do, I am suggesting to instead of just pin one
connection and then assume in all other executions that user wanted to use
that only pinned connection, return that connection ( in a way of new class
or id or ... ) and then allow connections to be used in commands.

Haris

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Badreddine
Karoui
Sent: Tuesday, October 20, 2009 16:28
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] The pinned connection

In the web environment not having control over which connection to use is
NOT a problem; It's a feature. The connection pooling/sharing is a
scalability feature. However, that can be an issue/restriction for some
special/edge and uncommon cases. For those cases, we have a special solution
that can be used; temporary pin the connection. BTW. This is similar to
pinning a .Net managed object when a unmanaged object need to keep a
reference to the managed object.

Badreddine

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Haris
Kurtagic
Sent: Tuesday, October 20, 2009 10:11 AM
To: 'MapGuide Internals Mail List'
Subject: RE: [mapguide-internals] The pinned connection

Difference is that using feature source id introduce problems we have now
and which we are trying to solve. And problem is as stated in RFC that
developer doesn't have control over which database connection is used when
he wants to execute commands.
If instead of feature source id, parameter would be connection then we
wouldn't have this issues and RFC.

Equivalent changes to API are already suggested in transaction RFC78. So
changes shouldn't be so difficult.
Just instead of transaction as suggested in that RFC we could use connection
as parameter.

I understand that making such changes will change existing API, I would much
reader introduce new clear API then changing existing one to support one
particular case and create existing API more difficult to understand and
use.

This is how I believe API should look like:

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)

Haris

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Badreddine
Karoui
Sent: Tuesday, October 20, 2009 15:30
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] The pinned connection

I'm not sure what is the difference between using the proposed fdo
connection and using the existing feature source id. It seems that
introducing the new connection will require more changes to the API since
all the existing commands use feature source id. If the proposed connection
will replace the feature source id, then that may not be acceptable since
that means clients will be pinning all connections. If this is an addition
to the API where both feature source id and connection will be used, then
this is cumbersome. I think pinning a connection is an exception/edge case
that should not be used unless it's absolutely necessary. As a result an
explicit API as suggested by the RFC is appropriate in this case.

Badreddine

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Haris
Kurtagic
Sent: Tuesday, October 20, 2009 7:08 AM
To: 'MapGuide Internals Mail List'
Subject: RE: [mapguide-internals] The pinned connection

I don't think we confused transaction with what is called pinned connection.
I think unnecessary confusion and limitations are in application when pinned
connection is hidden (assumed) to application as it is suggested in RFC.

My suggestion is that developer can acquire FDO connection and then use that
connection in ExecuteSql... functions. In that way developer have clear
picture what is he doing with which FDO connection and can execute any
combination of operations.

Reason why I am mentioning RFC78 is because same solution ( but only for
transactions ) was introduced in the RFC and I think we should combine those
and make one solution to satisfy all needs.

Haris

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Leaf Li
Sent: Tuesday, October 20, 2009 11:46
To: [hidden email]
Subject: [mapguide-internals] The pinned connection

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

Trevor Wekel

RE: The pinned connection

Reply Threaded

In reply to this post by Haris Kurtagic

I originally voted +1 on RFC 86. However, the ongoing discussion on the internals list has brought up some interesting points. Basically, we want to use the same Fdo connection across a set of Feature Service calls. Pinning the connection as per RFC 86 makes this possible with minimal API change.

However, it does conceal the fact that we are really using the same Fdo connection. ADO.NET and other "web" languages expose database connections as API objects http://msdn.microsoft.com/en-us/library/ms254507.aspx. To make the MapGuide API less obtuse, it would make sense to follow the same convention.

We could create a new class MgFeatureConnection which would mirror the required execute, select, etc. logic needed to meet the RFC 86 use cases. We would also have to add an OpenFeatureConnection method to MgFeatureService.

There would be no change to existing API functionality. MgFeatureService would still use pooled connections. In my opinion, "pinning" a database connection is a bit strange. Just grabbing an API object that represents the connection is much easier to understand and more in line with (every other?) API implementation.

Due to time constraints, I fully understand that implementing a pinned connection is a lot easier to implement than a whole new class. However, it may be possible to leverage much of the existing Server Feature Service implementation if an MgServerFeatureConnection parameter is added to various "command" classes. If the connection is null, then the resource identifier would be used to grab a pooled connection.

My +1 vote for RFC 86 still stands but I believe that a new API object would be a cleaner implementation.

Thanks,
Trevor

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Haris Kurtagic
Sent: October 20, 2009 11:52 AM
To: 'MapGuide Internals Mail List'
Subject: RE: [mapguide-internals] The pinned connection

I wouldn't call it deployment issue. The workaround you suggested is
possible but very ugly.

In my opinion API as it is suggested looks very unnatural, has limitations
and is much different than most of standard APIs.

I can guess that primary reason for such suggested solution in RFC was that
changes in existing API are minimal but it makes API looks really strange.

I would much rather see another set of ExecuteSql (e.g. ExecuteSql2 )
commands then trying to combine old and new in such way.

Haris

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Badreddine
Karoui
Sent: Tuesday, October 20, 2009 19:41
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] The pinned connection

You mean I cannot create multiple feature source IDs to the same data? That
sounds like a deployment issue; if an application requires the use of a
pinned connection and a regular connection at the same time, then I would
provision 2 feature source ids to the same datastore. Or may be I don't
understand that part?

Badreddine

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Haris
Kurtagic
Sent: Tuesday, October 20, 2009 1:34 PM
To: 'MapGuide Internals Mail List'
Subject: RE: [mapguide-internals] The pinned connection

?? Now you are getting me confused :)

Isn't proposed solution in RFC "PinConnection(MgResourceIdentifier
featureSourceId)" referring to Feature Source which identifies particular
Feature Source and it is one unique id for one feature source ?

Haris

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Badreddine
Karoui
Sent: Tuesday, October 20, 2009 19:29
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] The pinned connection

Why not? I just create 2 FSIDs and pinned them both. An application should
be able to use any number of unique FSIDs.

Badreddine

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Haris
Kurtagic
Sent: Tuesday, October 20, 2009 1:24 PM
To: 'MapGuide Internals Mail List'
Subject: RE: [mapguide-internals] The pinned connection

Yes, and one of issues of RFC is that you can't have another one

Haris

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Badreddine
Karoui
Sent: Tuesday, October 20, 2009 19:11
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] The pinned connection

I don't think there is anything assumed about what connection is pinned. If
a PinConnection is called using a specific feature source id, then all the
calls using that feature source id will use the pinned connection associated
with that fsid. There is no assumption made, the use of the pinned
connection is explicit through the use of the feature source id.

Badreddine

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Haris
Kurtagic
Sent: Tuesday, October 20, 2009 12:57 PM
To: 'MapGuide Internals Mail List'
Subject: RE: [mapguide-internals] The pinned connection

Hm, that is not true. Obviously it is a problem otherwise we wouldn't have
this RFC.
Connection pooling stays and it is common in web development but have
nothing to do with this discussion and RFC. Regarding connection pooling
nothing changes

I understand what you want to do, I am suggesting to instead of just pin one
connection and then assume in all other executions that user wanted to use
that only pinned connection, return that connection ( in a way of new class
or id or ... ) and then allow connections to be used in commands.

Haris

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Badreddine
Karoui
Sent: Tuesday, October 20, 2009 16:28
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] The pinned connection

In the web environment not having control over which connection to use is
NOT a problem; It's a feature. The connection pooling/sharing is a
scalability feature. However, that can be an issue/restriction for some
special/edge and uncommon cases. For those cases, we have a special solution
that can be used; temporary pin the connection. BTW. This is similar to
pinning a .Net managed object when a unmanaged object need to keep a
reference to the managed object.

Badreddine

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Haris
Kurtagic
Sent: Tuesday, October 20, 2009 10:11 AM
To: 'MapGuide Internals Mail List'
Subject: RE: [mapguide-internals] The pinned connection

Difference is that using feature source id introduce problems we have now
and which we are trying to solve. And problem is as stated in RFC that
developer doesn't have control over which database connection is used when
he wants to execute commands.
If instead of feature source id, parameter would be connection then we
wouldn't have this issues and RFC.

Equivalent changes to API are already suggested in transaction RFC78. So
changes shouldn't be so difficult.
Just instead of transaction as suggested in that RFC we could use connection
as parameter.

I understand that making such changes will change existing API, I would much
reader introduce new clear API then changing existing one to support one
particular case and create existing API more difficult to understand and
use.

This is how I believe API should look like:

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)

Haris

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Badreddine
Karoui
Sent: Tuesday, October 20, 2009 15:30
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] The pinned connection

I'm not sure what is the difference between using the proposed fdo
connection and using the existing feature source id. It seems that
introducing the new connection will require more changes to the API since
all the existing commands use feature source id. If the proposed connection
will replace the feature source id, then that may not be acceptable since
that means clients will be pinning all connections. If this is an addition
to the API where both feature source id and connection will be used, then
this is cumbersome. I think pinning a connection is an exception/edge case
that should not be used unless it's absolutely necessary. As a result an
explicit API as suggested by the RFC is appropriate in this case.

Badreddine

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Haris
Kurtagic
Sent: Tuesday, October 20, 2009 7:08 AM
To: 'MapGuide Internals Mail List'
Subject: RE: [mapguide-internals] The pinned connection

I don't think we confused transaction with what is called pinned connection.
I think unnecessary confusion and limitations are in application when pinned
connection is hidden (assumed) to application as it is suggested in RFC.

My suggestion is that developer can acquire FDO connection and then use that
connection in ExecuteSql... functions. In that way developer have clear
picture what is he doing with which FDO connection and can execute any
combination of operations.

Reason why I am mentioning RFC78 is because same solution ( but only for
transactions ) was introduced in the RFC and I think we should combine those
and make one solution to satisfy all needs.

Haris

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Leaf Li
Sent: Tuesday, October 20, 2009 11:46
To: [hidden email]
Subject: [mapguide-internals] The pinned connection

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

Leaf Li

RE: The pinned connection

Reply Threaded

In reply to this post by 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_______________________________________________

mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

UV-2

Re: The pinned connection

Reply Threaded

In reply to this post by Trevor Wekel

PROBLEM:
The dedicated connection API (here called pinned for some reason) is an
implicit change of state of the server.
This "implicit nature" permits it to add this API transparently for
other applications but it is the wrong approach passing API boundaries.

RISKS:
Loss of control.
Once the pinned connection has been requested further code uses it in
the same way as a pooled connection.
This keeps the changes to the API small, but its a hack as it changes
server behaviour unvisible to the user!
In a larger application this is hard or impossible to control and will
cause problems!

SOLUTION:
So introducing the API object for the "dedicated connection" is the
right way to go.
For the previous API the FDO connection will still be a pooled one (we
can still introduce configurable connection limits per user)

As Haris and me stated before: RFC78 and RFC86 need to be integrated
properly, they are too closely connected.

So we could have a dedicated connection as an API object which also
provides access to a gettransaction method.

WORKAROUND:
We could change the transaction semantics a little bit to allow the
dedicated connection to persists after a commit!
like:

{
MgTransaction tran = nullptr;

tran = MgFeatureService.StartTransaction(resourceId);
tran.Commit();
/// connection is returned to pool only in DTOR ~MgTransaction()

/// the following SQL runs in the same dedicated connection
MgFeatureService.ExecuteSql(resourceId, sql statement1, tran);
MgFeatureService.ExecuteSql(resourceId, sql statement2, tran);
MgFeatureService.UpdateFeatures(resourceId, MgFeatureCommandCollection, tran);

} /// end of context calls ~MgTransaction() end releases the dedicated connection

This seems to be able to deliver the required behavior without changing
API!
However, creating the dedicated connection and getting the Transaction
from it via API (Haris suggestions)
looks a lot better to me.

A discussion within a (preferably telephone) PSC meeting including
interested contributors seems like the efficient way to resolve such issues.
Maybe there are other more efficient ways to discuss those things than a
mailing list.....

I am happy to contribute some pieces here once decisions have been made.

Trevor Wekel wrote:

> I originally voted +1 on RFC 86. However, the ongoing discussion on the internals list has brought up some interesting points. Basically, we want to use the same Fdo connection across a set of Feature Service calls. Pinning the connection as per RFC 86 makes this possible with minimal API change.
>
> However, it does conceal the fact that we are really using the same Fdo connection. ADO.NET and other "web" languages expose database connections as API objects http://msdn.microsoft.com/en-us/library/ms254507.aspx. To make the MapGuide API less obtuse, it would make sense to follow the same convention.
>
> We could create a new class MgFeatureConnection which would mirror the required execute, select, etc. logic needed to meet the RFC 86 use cases. We would also have to add an OpenFeatureConnection method to MgFeatureService.
>
> There would be no change to existing API functionality. MgFeatureService would still use pooled connections. In my opinion, "pinning" a database connection is a bit strange. Just grabbing an API object that represents the connection is much easier to understand and more in line with (every other?) API implementation.
>
> Due to time constraints, I fully understand that implementing a pinned connection is a lot easier to implement than a whole new class. However, it may be possible to leverage much of the existing Server Feature Service implementation if an MgServerFeatureConnection parameter is added to various "command" classes. If the connection is null, then the resource identifier would be used to grab a pooled connection.
>
> My +1 vote for RFC 86 still stands but I believe that a new API object would be a cleaner implementation.
>
>
> Thanks,
> Trevor
>
>
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of Haris Kurtagic
> Sent: October 20, 2009 11:52 AM
> To: 'MapGuide Internals Mail List'
> Subject: RE: [mapguide-internals] The pinned connection
>
> I wouldn't call it deployment issue. The workaround you suggested is
> possible but very ugly.
>
> In my opinion API as it is suggested looks very unnatural, has limitations
> and is much different than most of standard APIs.
>
> I can guess that primary reason for such suggested solution in RFC was that
> changes in existing API are minimal but it makes API looks really strange.
>
> I would much rather see another set of ExecuteSql (e.g. ExecuteSql2 )
> commands then trying to combine old and new in such way.
>
> Haris
>
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Badreddine
> Karoui
> Sent: Tuesday, October 20, 2009 19:41
> To: MapGuide Internals Mail List
> Subject: RE: [mapguide-internals] The pinned connection
>
> You mean I cannot create multiple feature source IDs to the same data? That
> sounds like a deployment issue; if an application requires the use of a
> pinned connection and a regular connection at the same time, then I would
> provision 2 feature source ids to the same datastore. Or may be I don't
> understand that part?
>
> Badreddine
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Haris
> Kurtagic
> Sent: Tuesday, October 20, 2009 1:34 PM
> To: 'MapGuide Internals Mail List'
> Subject: RE: [mapguide-internals] The pinned connection
>
> ?? Now you are getting me confused :)
>
> Isn't proposed solution in RFC "PinConnection(MgResourceIdentifier
> featureSourceId)" referring to Feature Source which identifies particular
> Feature Source and it is one unique id for one feature source ?
>
> Haris
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Badreddine
> Karoui
> Sent: Tuesday, October 20, 2009 19:29
> To: MapGuide Internals Mail List
> Subject: RE: [mapguide-internals] The pinned connection
>
> Why not? I just create 2 FSIDs and pinned them both. An application should
> be able to use any number of unique FSIDs.
>
> Badreddine
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Haris
> Kurtagic
> Sent: Tuesday, October 20, 2009 1:24 PM
> To: 'MapGuide Internals Mail List'
> Subject: RE: [mapguide-internals] The pinned connection
>
> Yes, and one of issues of RFC is that you can't have another one
>
> Haris
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Badreddine
> Karoui
> Sent: Tuesday, October 20, 2009 19:11
> To: MapGuide Internals Mail List
> Subject: RE: [mapguide-internals] The pinned connection
>
> I don't think there is anything assumed about what connection is pinned. If
> a PinConnection is called using a specific feature source id, then all the
> calls using that feature source id will use the pinned connection associated
> with that fsid. There is no assumption made, the use of the pinned
> connection is explicit through the use of the feature source id.
>
> Badreddine
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Haris
> Kurtagic
> Sent: Tuesday, October 20, 2009 12:57 PM
> To: 'MapGuide Internals Mail List'
> Subject: RE: [mapguide-internals] The pinned connection
>
> Hm, that is not true. Obviously it is a problem otherwise we wouldn't have
> this RFC.
> Connection pooling stays and it is common in web development but have
> nothing to do with this discussion and RFC. Regarding connection pooling
> nothing changes
>
> I understand what you want to do, I am suggesting to instead of just pin one
> connection and then assume in all other executions that user wanted to use
> that only pinned connection, return that connection ( in a way of new class
> or id or ... ) and then allow connections to be used in commands.
>
> Haris
>
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Badreddine
> Karoui
> Sent: Tuesday, October 20, 2009 16:28
> To: MapGuide Internals Mail List
> Subject: RE: [mapguide-internals] The pinned connection
>
> In the web environment not having control over which connection to use is
> NOT a problem; It's a feature. The connection pooling/sharing is a
> scalability feature. However, that can be an issue/restriction for some
> special/edge and uncommon cases. For those cases, we have a special solution
> that can be used; temporary pin the connection. BTW. This is similar to
> pinning a .Net managed object when a unmanaged object need to keep a
> reference to the managed object.
>
> Badreddine
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Haris
> Kurtagic
> Sent: Tuesday, October 20, 2009 10:11 AM
> To: 'MapGuide Internals Mail List'
> Subject: RE: [mapguide-internals] The pinned connection
>
> Difference is that using feature source id introduce problems we have now
> and which we are trying to solve. And problem is as stated in RFC that
> developer doesn't have control over which database connection is used when
> he wants to execute commands.
> If instead of feature source id, parameter would be connection then we
> wouldn't have this issues and RFC.
>
> Equivalent changes to API are already suggested in transaction RFC78. So
> changes shouldn't be so difficult.
> Just instead of transaction as suggested in that RFC we could use connection
> as parameter.
>
> I understand that making such changes will change existing API, I would much
> reader introduce new clear API then changing existing one to support one
> particular case and create existing API more difficult to understand and
> use.
>
>
> This is how I believe API should look like:
>
> 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)
>
>
> Haris
>
>
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Badreddine
> Karoui
> Sent: Tuesday, October 20, 2009 15:30
> To: MapGuide Internals Mail List
> Subject: RE: [mapguide-internals] The pinned connection
>
> I'm not sure what is the difference between using the proposed fdo
> connection and using the existing feature source id. It seems that
> introducing the new connection will require more changes to the API since
> all the existing commands use feature source id. If the proposed connection
> will replace the feature source id, then that may not be acceptable since
> that means clients will be pinning all connections. If this is an addition
> to the API where both feature source id and connection will be used, then
> this is cumbersome. I think pinning a connection is an exception/edge case
> that should not be used unless it's absolutely necessary. As a result an
> explicit API as suggested by the RFC is appropriate in this case.
>
> Badreddine
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Haris
> Kurtagic
> Sent: Tuesday, October 20, 2009 7:08 AM
> To: 'MapGuide Internals Mail List'
> Subject: RE: [mapguide-internals] The pinned connection
>
> I don't think we confused transaction with what is called pinned connection.
> I think unnecessary confusion and limitations are in application when pinned
> connection is hidden (assumed) to application as it is suggested in RFC.
>
> My suggestion is that developer can acquire FDO connection and then use that
> connection in ExecuteSql... functions. In that way developer have clear
> picture what is he doing with which FDO connection and can execute any
> combination of operations.
>
> Reason why I am mentioning RFC78 is because same solution ( but only for
> transactions ) was introduced in the RFC and I think we should combine those
> and make one solution to satisfy all needs.
>
> Haris
>
>
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Leaf Li
> Sent: Tuesday, October 20, 2009 11:46
> To: [hidden email]
> Subject: [mapguide-internals] The pinned connection
>
> 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
>>

_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

1 2