Re: [Gnu-arch-users] [BUG] FEATURE PLAN: two stage commit

[Robert Collins]

On Tue, 2004-06-08 at 06:22, Tom Lord wrote:
> This will enable "distributed commit" -- a simultaneous, atomic commit
> to multiple branches (possibly in separate archives) at once.
> There are two ways (at least) to do it and I'm not sure which is best.

Excellent. Sorry for leaving all the context in, thought it easier..

> * Extend the "dumb server" archive protocol
> 
>   Clients should be able to "almost commit" a revision by
>   renaming it to something like:
> 
>     patch-<N>--<secret>--<other-revision>--<other-archive>
> 
>   instead of just "patch-<N>".
> 
>   Such a "half-committed" revision should act just like a 
>   held lock.
>
>   The lock-breaking algorithm has to be modified.   Asked to
>   break a half-committed revision, it _must_ ensure (creating
>   if necessary) the existence of the revision:

Why would it create this other revision? Wouldn't the absence of the
other revision be a sign to rollback?

>      <other-archive>/<other-revision>
> 
>   If that revision contains a header of the form:
> 
>       Two-stage-commit: <secret>
> 
>   then the lock can not be broken but instead may as well
>   be renamed to just:
> 
>       patch-<N>
> 
>   Otherwise (if the other-revision doesn't have that log header),
>   then the lock _is_ broken and the half-committed revision 
>   directory can be deleted at will.
> 
> 
> * Allow conditional changesets
> 
>   Replace the changeset part of a revision with a list of changesets,
>   each preceeded by a condition.
> 
>   For example, a revision might be defined by the rule:
> 
> 
>       if foo--1.0--patch-34 has the log header "Foo: bar" then
>         changeset is A
>       else
>         changeset is B
>       fi
> 
>   For a simple two-stage commit, A can be the changeset to apply if
>   my full txn succeeds, B can be a null-changeset indicating a 
>   failed txn.
> 
>   The full generality of being able to express arbitrary conditionals
>   might be useful or might not.   It might be ok to only permit
>   conditionals of the specific form illustrated above --- just enough 
>   to support two-stage commit.
> 
> 
> Either way, we gain the ability to commit changes to multiple branches
> atomically.   But there's a new problem: these meta-commits lack
> names.  We can't even begin to conceive of commands that would merge a
> multi-project commit unless there's some name by which we can refer to
> that commit.
> 
> A minimalist solution to that is to use the name of the last revision
> in a two-stage commit, the one that has the "Two-stage-commit:"
> header, as the name for composite commit.   It can have extra headers
> to say which other revisions were created in the same commit.

I think that will suffice, so long as we make the log file a
fully-present/not-present condition.

On a related note, I am planning on implementing two-phase commits with
non-tla resources. Would this fit well within your architecture above?
My current thoughts are just to modify commit & lock-revision to be able
to leave a all-but-committed changeset in place, and to
renamed-to-fully-committed from the command line. A variant on the
extended-dumb-server protocol seems most sane to me.

Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.

signature.asc
Description: This is a digitally signed message part