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

[Jan Hudec]

On Tue, Jul 13, 2004 at 09:29:29 +1000, Zenaan Harkness wrote:
> > [...]
> So my immediate thought is - has anyone read the "alternative commercial
> product"'s manual to see what it does?

Whatever it does, it likely does not apply here. The problem is, that
our "server" is just a filesystem server that knows nothing about
transactions (ftp, sftp, webdav or plain, not-necessarily-posix fs). It
just knows how to do directory rename and does it atomicaly. It's the
only operation that it does atomicaly. It has no link nor symlink.

So we have to forget a DB-like client-server model. It does not apply
here.

> OK, back to the start of the thread:
> 
> 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.
> 
> I'll ignore the "separate archives" bit here - and I think we should
> ignore it unless proven necessary: AIUI, a large point of the arch

You can't forget it. If you forget it, you risk inventing schemes, that
don't allow it.

> model is that changes can be applied to alternative trees in different
> sequences. That's how the whole thing becomes decentralized and
> therefore scalable to 100s if not 1000s of repos. Give that up not.
> 
> So we need to commit to multiple branches atomicly.
> 
> Well, lock those branches.
> 
> And the simplest way to lock - serialize commits of all 'changes'
> (including these new 'meta' changes), to server's archive.

The problem is, that transactions can't be expressed in terms of locks
alone, because locks won't give you atomic operations.

The current locking is not a true locking with a property, that once you
have the lock, you can't loose it. You can -- and it must properly fail
the transaction. The trick here is, that the lock is the revision to
commit. Someone may delete it under you -- and the final rename cleanly
fails.

> This implies a meta-change is just another changeset: no point having
> separate entities here; keep it uniform to the greatest extent possible.
> As Hans Reiser would say, the less numerous the primitives, then
> the fewer communication interfaces between primitives are needed
> (which grow exponentially with the number of primitives otherwise),
> and therefore the greater the flexibility of the system.
> 
> Then we have two clients, which, instead of submitting sequences
> of changes A+B+C and B+D+E, simply submit two changes X and Y, which
> happen to contain ABC and BDE respectively.
> 
> Whichever change, X or Y, the server first accepts and commits, succeeds.
> The client submitting the second change is rejected.

That's on an interface somewhere inside libarch. There it can work like
that. But we are talking about implementation of the server!

> [...] 
> And if performance is within this realm of reasonableness that I find it
> hard to think outside of, branch-locks would be enough to do what we need
> to do here. There are established Posix interfaces for creating
> "lock files" - so just have such a standard zero-byte lock file for each

"Estabilished posix interface for creating lock files" includes link
operation. Windows don't have link operation.

We also don't need things like hierarchical locks, nor can have them.
There is only one way to change a version -- add a revision to the end.
Once writen, the archive never changes.

Also, when the transaction spans multiple archives, there is no chance
of locking the world.

> branch. Of course if you don't grab (create) the lock file, then the
> naive implementation is to poll until it is available. Which is why you'd
> probably want a 'proper' locking mechanism in the server (ie. in-memory
> per-branch semaphor or whatever the appropriate lock term is).

We don't have that server.

-------------------------------------------------------------------------------
                                                 Jan 'Bulb' Hudec 
<address@hidden>

signature.asc
Description: Digital signature