+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 )
