fog@mixadlive.com said:
if you want to use the per-cursor commit extension of psycopg, you need to call the .commit() method on the *cursor*. calling it on the connection will commit on all the cursors derived from the connection.
I know (I wrote ODBC drivers for a living, among others a PostgreSQL one :-)). I sorta expected the Z SQL Connection to do the "right thing", but it forwards the TM messages to the connection, not to individual cursors.
mmm... i think that zope instantiate a connection for every thread. in the psycopg case, every zope thread gets one connection and one cursor.
Let's hope so, although I haven't been able to discern the code that does that bit of magic. Is there a document somewhere that describes what Zope does, thread-wise, when handling requests? Anyway, I plunged into my code and FYI, this is how I'm now dealing with it: - select statements grab and release a cursor; - update statements grab a cursor, wrap them in a TM subclass and register the result with the transaction manager. The cursor is also registered in a thread map, so that subsequent update statements in the same thread/transaction reuse the cursor. When the Zope TM calls finish()/abort(), the cursor is committed and released (and removed from the thread map). - session access (updating the "last accessed" timestamp on mostly every request) is done through a special global cursor, which does a commit every 10 or so updates keeping disk write load for this non-critical piece of information low. The end result is acceptably low connection usage and correct transaction scoping. Now I only have to find that (*&@#$ deadlock somewhere in my code ;-). -- Cees de Groot http://www.cdegroot.com <cg@cdegroot.com> GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD 1986 F303 937F E098 9E8B -- Cees de Groot http://www.cdegroot.com <cg@cdegroot.com> GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD 1986 F303 937F E098 9E8B