WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] /proc/xen/xenbus supports watch?
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Wed, 21 Sep 2005 10:39:46 +0100
Cc: xen-devel List <xen-devel@xxxxxxxxxxxxxxxxxxx>, Steven Hand <steven.hand@xxxxxxxxxxxx>, Christian Limpach <Christian.Limpach@xxxxxxxxxxxx>
Delivery-date: Wed, 21 Sep 2005 09:32:37 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1127214064.2656.45.camel@xxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <5d7aca9505090801025f3d5771@xxxxxxxxxxxxxx> <3d8eece205090803381b818f18@xxxxxxxxxxxxxx> <1126226609.25110.3.camel@xxxxxxxxxxxxxxxxxxxxx> <3d8eece205091302422ac74f77@xxxxxxxxxxxxxx> <1126657264.7896.20.camel@xxxxxxxxxxxxxxxxxxxxx> <1126689530.4415.10.camel@xxxxxxxxxxxxxxxxxxxxx> <3d8eece205091405555a2871fc@xxxxxxxxxxxxxx> <1126748390.12119.33.camel@xxxxxxxxxxxxxxxxxxxxx> <aad156145bec3bd706ef69c0e96341a7@xxxxxxxxxxxx> <1126945564.29203.116.camel@xxxxxxxxxxxxxxxxxxxxx> <bf4f0a8e8b96fd1ac2701daa78ca52c6@xxxxxxxxxxxx> <1127088661.23870.47.camel@xxxxxxxxxxxxxxxxxxxxx> <d7335251fd831e43f944d94e22da3878@xxxxxxxxxxxx> <1127214064.2656.45.camel@xxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

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