[Zope] Three questions: No response in Mozilla, VersionLockErrors, and transactions in Postgres with ZPoPyDA

[Dieter Maurer]

Scott Anderson writes:
 > Right now I'm running Zope in single-threaded mode, just to forstall any
 > questions of that nature.
 > 
 > Also: Zope 2.3.3 binary on RedHat 6.2, PostgreSQL 7.1, PoPy 2.0.2,
 > ZPoPyDA 1.2, exUserFolder 0.5.0
 > 
 > 
 > Question 1:
 > 
 > There is something very odd with Postgres and transactions. I will very
 > often find a postgres process in the list with "idle in transaction".
 > Typically when that happens, I can check the logs and discover that a
 > commit has not been performed, and database information will not be
 > written. One time while the site was idle, I couldn't add an index
 > without shutting the Zope process down as it had a transaction open.
 > When this happens, I can sometimes run a ZSQL method with only the word
 > "commit;" in it to unstick everything.
About two to 4 months ago, someone posted a question (I think to
"zope-dev") about dubious code in Zope's transaction management
that could lead to dangling transactions.

Jim Fulton replied that the poster was unfortunately right.

I would have expected that the problem were fixed in the latest
Zope release. Maybe, it is not....

Search the (searchable) mailing list archives (at NIP)
and check whether the dubious code is still there.

 > Question 2: 
 > 
 > Whenever I use the version feature, working in a version will eventually
 > cause my users to get a VersionLockError just viewing the site.
 > Typically I'll see exUserFolder mentioned in the error:
 > ...
 > commit
 >     (Info: (('Products.exUserFolder.pgPropSource.pgPropSource',
 > 'pgPropSource'), '\000\000\000\000\000\000\033\214', ''))
 >   File /usr/local/dev/zope/lib/python/ZODB/FileStorage.py, line 663, in
 > store
 >     (Object: /usr/local/dev/zope/var/Data.fs)
 > VersionLockError: (see above)
I appears that something performs writes although you expect it
to read only.

The exception value should tell you the "oid" and the
version that is looking the object (the latter is not interesting).
To narrow down what object is written unexpectedly,
you can load the object from ZODB (e.g. via the Zope monitor
or directly from a Python script (external, not Zope's; Zope
need to be stopped):

     import Zope
     import GLOBALS
     conn= GLOBALS.DB.open()
     obj= conn[oid]

You can then analyse "obj", e.g. determine its class: "obj.__class__".



Dieter