sqlobject-discuss

[SQLObject] releaseConnection and Transactions

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

Howdy again,

I've been having some trouble with the fact that releaseConnection
does a rollback() if autoCommit is false and not 'exception' and
supportTransactions is set to True. Namely, if in my application (Zope
3-based) I've set autoCommit to false because Zope takes care of
commiting the transaction at the right time, but then it reaches this
path and anything that I do gets rolled back. So, the solution for me
was to set supportTransactions to False, which doesn't seem to affect
anything, but feels icky anyway. Is there any special reason for the
rollback() there? The line in question is 98 of DBConnection.

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

Simulations are like miniskirts, they show a lot and hide the essentials.
		-- Hubert Kirrman

Re: [SQLObject] releaseConnection and Transactions

[Ian B. <ia...@co...>]

On Thursday, September 25, 2003, at 05:11 PM, Sidnei da Silva wrote:
> I've been having some trouble with the fact that releaseConnection
> does a rollback() if autoCommit is false and not 'exception' and
> supportTransactions is set to True. Namely, if in my application (Zope
> 3-based) I've set autoCommit to false because Zope takes care of
> commiting the transaction at the right time, but then it reaches this
> path and anything that I do gets rolled back. So, the solution for me
> was to set supportTransactions to False, which doesn't seem to affect
> anything, but feels icky anyway. Is there any special reason for the
> rollback() there? The line in question is 98 of DBConnection.

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.

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.

   Ian

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.)