Re: [Xen-devel] /proc/xen/xenbus supports watch?

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

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
> migration 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.

Either we allow clients to lock down sections of the xenstore hierarchy 
for unbounded periods of time (unacceptable since we do not trust all 
clients) or we have to handle transaction failure in the clients. The 
only exception to this I can think of is read-only transactions, where 
you can take a read-only consistent snapshot of the store when the 
transaction begins and guarantee eventual success (even here we may 
want a timeout to avoid resource hogging). Apart from that, on failure 
the client *has* to execute its transactional code again -- the values 
it writes to the store may be dependent on values it reads as part of 
the same transaction. If the transaction is failed because some of 
those values it read are now stale (or might be stale, because a leased 
lock was revoked), the transaction replay has to include re-execution 
of the client code -- it cannot be hidden in the transactional API 
(e.g., just replaying the transactional writes from the previous failed 
attempt may be incorrect if those writes are based on stale reads from 
the previous failed attempt).
This is the price for providing ACID guarantees (well, A, C and I at 
least, and without atomicity, consistency and isolation you are not 
implementing transactions as understood by every computer scientist).
If we have to make failure visible to clients anyway (and I'm sure we 
do), it does at least greatly simplify things like xenstored restart 
and migration. Transactions are simply failed.
 -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel