On Mon, Jan 22, 2007 at 11:05:58AM -0500, C. Michael Pilato wrote:
> Peter Lundblad wrote:
> > This sounds cool, although it might be interesting to see a design for
> > how to solve this in FSFS before investing too much in the rest.
> > What compatibility/format change issues will we have?
>
> Yeah, that was my next step. There are a couple of approached that come
> quickly to mind:
>
> lock repos
> check for state that should guarantee success (read-only)
> do work
> if failure (should only be non-Subversion reasons):
> die
> unlock repos
>
> Or:
>
> lock repos
> do work, keeping track of the how-to-undo-it list
> if failure (Subversion or non-Subversion reasons):
> undo-it
> if failure ((should only be non-Subversion reasons):
> die
> unlock repos
>
> But I definitely need to spend some more time thinking about the problem
> before diving in. And while doing so, I'll sing a song about how
> beautiful subsystem-provided transactions and atomicity are.
>
Locking in FSFS is currently done under the FS-wide write-lock, so
making it able to lock multiple locks at once should be easy (see
libsvn_fs_fs/lock.c:lock_body()/unlock_body(). I imagine that switching
those to take an array of the batons they currently get would work).
Unless I misunderstand, no format changes should be required.
I think it might be easier to check to see whether all the locks are
valid before updating, otherwise you'll need to work out how to
'unsteal' locks, for example.
That admittedly doesn't give us a complete ACID solution - we're missing
isolation, because the locks are visible immediately they're created.
But that wasn't a goal, was it? (you're just implementing an atomic
lock-many, aren't you?).
Regards,
Malcolm
- application/pgp-signature attachment: stored
Received on Mon Jan 22 18:50:46 2007