Checking active transactions

74 views
Skip to first unread message

Christoph Zwerschke

unread,
Feb 22, 2008, 5:29:04 AM2/22/08
to sqlal...@googlegroups.com
In TurboGears 1, requests are encapsulated between a session.begin() and
session.commit() call (or session.rollback(), if there was an error).

Starting with SA 0.4.3, the commit() raises an exception if the
transaction has been already rolled back in the request (explicitly or
due to an error). So TurboGears needs to check whether the transaction
is active before the session.commit() call. We currently do this by
storing the transaction as the return value of session.begin() and then
checking transaction.is_active (or transaction.session.transaction for
earlier SA versions).

This gets complicated since the transaction may be restarted during a
request and can change. So I think it would be handy to tell directly
from the session whether the transaction is active or not.

We are using *scoped* sessions in TruboGears, and the problem is that
the transaction attribute is not available in ScopedSessions, so I can
not check for session.transaction.is_active. I can get the original
Session by calling session, so session().transaction.is_active would
work, but it does not feel right. I guess it is by intent that the
session attributes are not visible in scoped sessions.

So how about adding a property is_active to the Session that would call
session.transaction.is_active? Then you could do:

if session.is_active:
session.commit()

-- Christoph

Michael Bayer

unread,
Feb 22, 2008, 11:21:13 AM2/22/08
to sqlal...@googlegroups.com

thats fine...but also why cant you just say try: session.commit()
except: session.rollback(); raise ?

Christoph Zwerschke

unread,
Feb 22, 2008, 1:11:50 PM2/22/08
to sqlal...@googlegroups.com
Michael Bayer schrieb:

> thats fine...but also why cant you just say try: session.commit()
> except: session.rollback(); raise ?

This would raise an error when the session is already inactive. I don't
want an error in this case. On the other hand, if I remove the raise
statement, then errors on commit would be swallowed. I thought about
catching only InvalidRequestError, but this might also catch too much.

-- Christoph

Reply all
Reply to author
Forward
0 new messages