[Zope-DB] question on zope DAs

[Federico Di Gregorio]

On Tue, 2001-10-16 at 23:10, Matthew T. Kromer wrote:
[snip]
> >looks like zpsycopg rollbacks any uncommited transactions before
> >starting another, both zpopy & DCOracle2 ignore calls to _begin,

this is a leftover. psycopg used to keep transactions open and the
rollback was required to obtain right values from 'now', 'today', etc.

[snip]
> We've had some interesting discussions about RDBMS support w.r.t. the 
> Zope transaction machinery.  The problem (as you notice) has to do with 
> trying to synchronize transactions.
> 
> Generally, there's going to be some kind of commit() function called 
> when Zope commits a transaction, or an abort() when Zope rolls it back. 
>  OK, so far so good... :)  A side effect of this means that as long as a 
> connection object is not shared between threads (and thus between 
> transactions) except via a commit/abort boundary, you dont have to be 
> precise about starting a new transaction (IMHO -- I dont know that all 
> DB systems dont want an explicit "transaction start" mechanism to be 
> invoked.)
> 
> The kicker is that rollback is really two-phase in Zope, and that some 
> RDBMS DAs may do the wrong thing, or the right thing at the wrong time. 
>  Here's a message URL that was referred to in an e-mail recently:
> 
>     http://aspn.activestate.com/ASPN/Mail/Message/525729
> 
> in which some similar issues are discussed.  The gist of the argument is 
> that the DA shouldnt commit data until the ZODB has done its first phase 
> commit (ie no conflicts or errors), and instead should work on the 2nd 
> half.  Aborts though, need to abort everything, including ZODB.

ok. lately there were reports of problems using zpsycopgda with zeo. i
am beginning to think that the problems derive from the fact that
zpsycopgda was not developed on good documentation but on a
try-and-see-if-it-works base. your talk about the two-phase commit
protocol is convincing me even more. 

can the people who wrote the db stuff in zope just tell us *what*
*exactly* is a zdba supposed to do in every function?

> Techically, the DA should support a two-phase commit protocol, where it 
> gets a "prepare" to commit and a final "commit."  I dont know of any 
> which do this, though.

i don't think. i looked at the sources of all the major dba and never
seen such a thing.

> And as an aside, database connection/recovery for detecting stale or 
> lost connections is very ad hoc.   Its something that I want to see 
> changed sometime.  Some DA's (ZOracleDA is one) just try to open the 
> connection again on an error.

zpsycopgda does the same. <g>

> I'd also endorse a notion of setting transaction ids for RDBMS systems 
> which support it, so that a single connection object can participate in 
> multiple transactions.  This is not a high priority in Fredericksburg, 
> though.

the problem is that zope does not exploit the thread safety of the
drivers. for example, psycopg is fully level 2 thread safe (connections
can be shared among threads) but zope force us to create one psycopg
connection per-thread. there is no way to create just one cursor per
thread.

ciao,
federico

-- 
Federico Di Gregorio
Debian GNU/Linux Developer & Italian Press Contact        fog@debian.org
INIT.D Developer                                           fog@initd.org
   God is real. Unless declared integer. -- Anonymous FORTRAN programmer