From: Gavin_King/Cirrus%<CI...@ci...> - 2002-03-04 07:16:17
|
As a logical extension to some of the stuff we've talked about and also bringing in some other things people have asked about, I think I can start to see a new approach to the whole relationship between sessions and connections. We have already considered changing the commit()/cancel() process to the more fine grained: Session.flush() Session.connection().commit() Session.connection().rollback() Session.close() Now, to support a much more useable "optimistic locking with versioning" scheme, we could add the following: Session.disconnect() Session.reconnect() disconnect would return the connection to the pool and reconnect would grab a new connection. This is (a) more efficient than and (b) more useable than the suggested approach in the documentation which is to do some selects with Connection.setAutocommit(true) and then start a transaction to do the updates. Session.disconnect() would relinquish any read locks (by releasing the connection) and would need to be proceeded by a connection().commit() if any updates had been performed. Updates performed subsequent to a Session.reconnect() would depend upon the checking of version numbers to maintain consistency. Write locks could easily be re-obtained by using Session.lock() (which also, in the current implementation, checks the version number). How I envisage this stuff would be used is, for example, in a stateful session bean where we can't keep a connection (or transaction) open between invocations from the UI. The bean would disconnect the session at the end of each operation and reconnect at the start. Currently you would need a new Session each time which would force you to reload a versioned object, even if all you were going to do was update it. So the session would come to represent a real business transaction that might span multiple database transactions (using optimistic locking with versioning to enforce consistency). I'm *really* keen on this approch, so shoot me down if necessary.... |