A failed join leaves zope.sqlalchemy in an inconsistent state

[hgarus]

I am not entirely sure if this is a bug, but the current behavior could at least be considered suboptimal:

When the ZopeTransactionExtension triggers a join, while the state of the zope transaction is COMMITFAILED a TransactionFailedError will be raised and the _SESSION_STATE entry of the sqlalchemy session will be left behind.

If the sqlalchemy session is reused in the future (ie because it is threadscoped) it won't be joined to the zope transaction at all, since it already has a corresponding entry in _SESSION_STATE. This causes the sqlalchemy transaction to remain open, which can lead to a database transaction being "wedged" until it is closed due to a database timeout or a restart of the zope instance.

I am not sure if a join should even be attempted if the transaction is in COMMITFAILED. Doing operations on the sqlalchemy session while the zope transaction is in this state could probably be considerer a bug on the user's side. But I believe this should be addressed in some way.

[jinty]

This definitely sounds like a bug to me. The join_transaction() call should definitely raise an error loudly, but not cause a "wedged" session and affect future transactions.

Could you write a test which demonstrates the failure? For example testAbortAfterCommi" is a regression test for a problem which resulted in a similar "wedged" session.

[hgarus]

I have added a test demonstrating this behavior:

hgarus@970a2da

[jinty]

Thanks. I committed your test and a fix:

a3d9c95

[cjw296]

Any idea when the next release will be?

[jinty]

On Fri, Aug 30, 2013 at 01:39:08AM -0700, Chris Withers wrote:

Any idea when the next release will be?

Nope.

Brian Sutherland

[mgedmin]

PyPI says this about zope.sqlalchemy:

Package Index Owner: laurencerowe, chrism

I believe laurencerowe is @lrowe and chrism is @mcdonc. Only they can make releases.