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