[Zope-DB] question on zope DAs
Federico Di Gregorio
17 Oct 2001 11:22:01 +0200
On Tue, 2001-10-16 at 23:10, Matthew T. Kromer wrote:
> >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.
> 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
> 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:
> 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,
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
Federico Di Gregorio
Debian GNU/Linux Developer & Italian Press Contact firstname.lastname@example.org
INIT.D Developer email@example.com
God is real. Unless declared integer. -- Anonymous FORTRAN programmer