Hi Shane,

On 23/05/2012 16:27, Chris Withers wrote:
Okay, the issue appears to be that, in some circumstances, RelStorage is
leaving the read connection with an open transaction that isn't rolled

Upon investigation, this turns out to be the history method itself! :-)

Switching to the following patch also solves the problem:

diff --git a/relstorage/storage.py b/relstorage/storage.py
index 2d592d3..3fa792b 100644
--- a/relstorage/storage.py
+++ b/relstorage/storage.py
@@ -1053,6 +1053,7 @@ class RelStorage(
             return res
+            self._load_conn.rollback()

     def undo(self, transaction_id, transaction):

However, that raised more questions for me:

- How does RelStorage usually rollback the _load_conn in a non-write transaction?

- Why doesn't this kick in when viewing the history method?

My guess as to why ZODB.tests.HistoryStorage:HistoryStorage.checkSimpleHistory passes is that everything is done with the same thread/connection, and so a consistent view of the data is seen.

More confusing: having dropped the zserver-threads down to one and from looking at the results of:

select * from pg_catalog.pg_stat_activity where datname='myrelstorage';

...it appears that there's:

- one connection for reads

- one connection for writes, which is opened when first used.

Okay, as expected.

- one connection for viewing history.

I can't see where/why this final connection is opened...

Shane, little help?


Simplistix - Content Management, Batch Processing & Python Consulting
            - http://www.simplistix.co.uk
For more information about ZODB, see http://zodb.org/

ZODB-Dev mailing list  -  ZODB-Dev@zope.org

Reply via email to