[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] [BUG] FEATURE PLAN: two stage commit
From: |
Robert Collins |
Subject: |
Re: [Gnu-arch-users] [BUG] FEATURE PLAN: two stage commit |
Date: |
Mon, 12 Jul 2004 13:48:52 +1000 |
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
- Re: [Gnu-arch-users] [BUG] FEATURE PLAN: two stage commit,
Robert Collins <=