[Zope] (no subject)

[Cees de Groot]

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