Re: [SQLObject] releaseConnection and Transactions

[Sidnei da S. <si...@pl...>]

On Fri, Sep 26, 2003 at 01:03:23AM -0500, Ian Bicking wrote:
| Looking at that again, I don't know that the code is really correct.  
| The difficulty is that objects should know when they are rolled
| back.  
| I know ZODB handles this as well; I'm not as clear about how that fits 
| into SQLObject.  Specifically, Transaction.rollback expires all the 
| instances so that invalid cached values are removed.

Humm.. So thats why it needs to know when its rolled back. I haven't
really really looked under the hood to see if its Connection.rollback
or Transaction.rollback which is being called by the Zope
machinery. But we can make it call Transaction.rollback if that's not
being done yet.

| So, I don't know if the current behavior is really right, but I don't 
| think removing it is quite right either.  Though it may be appropriate 
| to set supportTransactions to false, because in a Zope environment the 
| transactions are being handled by Zope, not by SQLObject.  Though Zope 
| is not always the final work on transactions either -- it's sometimes 
| necessary to commit or rollback transactions in the middle of a 
| request.  So that has to be factored in too.  So, in summary, I'm not 
| sure.

AFAICT, its not needed (nor desired) to commit or rollback a
transaction in the middle of a request, unless an exception occurs, in
which case you *must* rollback. Setting supportTransactions to false
has worked very smoothly for me. The SQLObject is being registered
with the Zope transaction manager, so when Zope calls
Transaction.commit() or Transaction.rollback(), the call is propagated
to SQLObject.

[]'s
-- 
Sidnei da Silva <si...@pl...>
dreamcatching :: making your dreams come true
http://dreamcatcher.homeunix.org

Computers don't actually think.
	You just think they think.
		(We think.)