[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: |
Tom Lord |
Subject: |
Re: [Gnu-arch-users] [BUG] FEATURE PLAN: two stage commit |
Date: |
Mon, 12 Jul 2004 14:38:14 -0700 (PDT) |
> From: Jason McCarty <address@hidden>
> Tom Lord wrote:
> > > Anyway, hopefully the above will contribute in some way.
> > Of course. It helps to get "many eyeballs" on the design before it's
> > finalized. In this case, it got me to remember and write down why I
> > decided that a commit was needed to kill a composite transaction
> > rather than just a `tla lock-revision --break'.
> Something I should have mentioned before then: If I understand
> correctly, if B, C, ... are half-committed and dependant on A, one way
> of breaking the lock on B is to commit A', which makes the commit of A
> fail, thus causing B, C, ... to be uncommitted. What if the person who
> wants to break the lock on B doesn't have permission to commit
> A'?
Tough luck, for the most part. Giving out/managing permissions to
commit to a particular archive has to take that into account.
Of course, there is still the usual range of by-hand work-arounds
that, formally speaking, break consistency but as a practical matter
are often, well, practical.
> Further, whose responsibility is it to actually remove the half-
> committed B, C, ... when it's discovered that committing A must fail
> (especially if the process committing A dies in the middle of things)?
Anyone with write permission can do it the same way anyone can break a
lock.
-t