+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 _______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )