On Wed, 2005-09-21 at 10:39 +0100, Keir Fraser wrote:
> On 20 Sep 2005, at 12:01, Rusty Russell wrote:
>
> > The only issue is that, in the case of migration, the new xenstored
> > won't know about any transaction currently in progress. We can either
> > migrate transactions (easy for clients), or return EAGAIN for the
> > next
> > operation (easy for xenstored, sucks for clients).
>
> Well, you know we already disagree very strongly on this.
Perhaps I was unclear?
It's not the *commit* that fails with EAGAIN, but *any operation*
(read/write/dir, etc), in this scenario. Unlike daemon restarts, where
we can simply re-establish transactions, even if the eventual commit is
doomed to fail. (I sent such code to Christian, but abandoned it
because we had to change everything else anyway).
Now, reread the paragraph you quoted. Is my question clearer now? I
really do want to know what you think, Should we try to migrate
transactions, or label the xenstored API clearly that any operation
inside a transaction can return EAGAIN if you are inside a domU using
the xenbus device? Or can you see a third way?
(BTW, your analysis of the use of locks to provide ACID is flawed, but
since I've had to abandon that approach for another reason I'll not
waste time now in an academic argument: that's for pubs and IRC).
Have I unconfused the issue?
Rusty.
--
A bad analogy is like a leaky screwdriver -- Richard Braakman
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home