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
back.
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(
break
return res
finally:
+ self._load_conn.rollback()
self._lock_release()
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?
Chris
--
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
https://mail.zope.org/mailman/listinfo/zodb-dev
