Re: [SQLObject] Hung transactions on object creation

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

On Monday, October 27, 2003, at 02:46 PM, Sidnei da Silva wrote:
> | Rolling back in that circumstance is way too aggressive.  It should 
> be
> | possible to catch the exception and handle it within the transaction.
>
> That's what I thought, but it doesn't seem to be getting far enough to
> call rollback() from what I can see, which is really strange. The
> current situation is that I have the SQLObject registered with Zope's
> TransactionManager and when there's an exception, Zope aborts the
> transaction, calling SQLObject's rollback() method. This works fine in
> all cases, *except* when the exception happens in SQLObject.new (or so
> it seems).
>
> | Do you have an idea what "idle in transaction" means, and what's
> | causing it?  Are we talking about database-generated exceptions (like
> | IntegrityError), or Python-generated (ValueError or something)?  Or
> | either?
>
> It is waiting either for a rollback or a commit (eg: its a transaction
> in progress). The exception is TypeError, generated inside
> SQLObject.new(). When I call the rollback() there before raising the
> exception, it works just fine.

So for some reason an exception propagated out of SQLObject.new won't 
cause the TransactionManager to roll back the transaction, even though 
exceptions anywhere else do work.  How odd.  What does SQLObject's 
connection to TransactionManager look like?

Does it work any differently if you successfully create (or interact 
with) a SQLObject instance, then get an exception in SQLObject.new?  
(As opposed to an exception in SQLObject.new being the first query for 
the transaction)

--
Ian Bicking | ia...@co... | http://blog.ianbicking.org