+1 for adding _vote() to TM.py all XAs/DMs should have voting privleges, even if they don't exercise such. the default behavior should be due to nothing, for as with people in a democracy most tm subclasses won't vote. -kapil On Tuesday 04 June 2002 12:54 pm, Leonardo Rochael Almeida wrote:
In a chat with Kapil at #zope we came to the conclusion that most Zope database adaptors don't really implement two phase commit, because they make no effort, during the 'vote' phase (the first phase of the tpc) to make sure that the commit will go thru without errors.
For example, if you have the following schema in postgresql:
CREATE TABLE "passwd" ( "username" character varying(64) UNIQUE, "password" character varying(64) NOT NULL, "roles" character varying(255), Constraint "passwd_pkey" Primary Key ("username") );
CREATE TABLE "userproperties" ( "username" character varying(64) NOT NULL references "passwd" (username) DEFERABLE INITIALLY DEFERRED, "propname" character varying(128) NOT NULL, "value" text NOT NULL, );
This schema allows an entry in the 'userproperties' table to exist without an equivalent user in the 'passwd' table before the end of the transaction.
If, on commit, there still isn't a user with the same 'username' on the 'passwd' column, postgres will raise an error and won't let the commit go thru.
Now all the current DA implementations that I know of call the database commit only in the second (or finish) phase of the tpc, which will result in a locked down Zope, as Zope is not very much fond of people bailing on him on the second phase.
Now the correct solution for this, as far as postgres is concerned, is to execute the query, 'SET CONSTRAINTS ALL IMMEDIATE' in the 'vote' phase, since no other query will be executed between this query and the commit. Postgresql will raise an error while trying to execute this query if any coinstraint is yet to be satisfied, so Zope will be able to cancel the transaction to all those registered in the transaction machinery. And if the postgresql documentation is correct, 'SET CONSTRAINTS...' is an SQL92 and SQL99 standard, so other db's might be able to benefit from this.
The problem is that lib/python/Shared/DC/ZRDB/TM.py doesn't provide a _vote() slot which should be called by tpc_vote(). TM documentation should mention that this slot should be overriden, just like _finish() and _abort(). It should also mention why this slot should be overriden ("consistency this, consistency that, yadda yadda..").
The nazi bastard in me wants the default implementation of this slot to raise an error to remind people to override it. If your DA doesn't need, or can't, implement a _vote() for some reason, you should explicitly override it to do nothing. However I know that breaking other people's DA is not nice :-)
The not so nazi bastard in me says that the default _vote() implementation should zLOG a warning about '_vote()' not being implemented, but I know that even this might be too much to ask, since logfiles everywhere would go crazy.
Anyway, this may be a little late, but I believe that implementing a do-nothing _vote() that is called by TM.tpc_vote() is a small and unintrusive change but a change that is important enough to deserve to be included in 2.6, so that DA authors take notice and implement it where possible.
I'd volunteer to make this change myself if my commiter's agreement had been commited (I'm looking at you Paul Everitt). I know that I'll bug the Psycopg guys once this change is thru.
Leo