On Sat, 2005-09-17 at 18:40 +0100, Christian Limpach wrote:
> On Sat, Sep 17, 2005 at 06:26:04PM +1000, Rusty Russell wrote:
> > What was the reason for wanting multiple transactions per connection?
> > Changing the interface is going to be a PITA, so we should figure out if
> > we're going to need that soon...
>
> It solves the immediate problem of making the xenbus lock in the kernel
> driver more fine grained. I'm not too happy with how a userspace
> program can block all xenbus access for that domain at the moment,
> even if this is limited to the root user.
Sure, and we already have the concept of separate transports, so I think
we should use them.
> Additionally, I believe
> it's necessary to support reconnect to a different store after
> restore, allowing the store daemon or the xenbus driver to distinguish
> operations which are part of an incomplete transaction from operations
> which are not part of a transaction at all.
And I think you're wrong; it's unnecessary and it doesn't actually help.
The code will show.
> Finally, adding transaction
> ids later will be a lot more difficult.
Unless we introduce a xs_transaction_context() call, and leave it
implicit?
> I also find the current behaviour a bit odd, we support operations
> outside of transactions but once you start a transaction, every
> operation you make is part of that transaction. i think we should
> either require to always be in a transaction or always allow outside
> of transaction operations.
We could drop implicit transactions; it would simplify the code a bit.
I didn't do this because it seems a bit silly for simple monitoring
tools. The start/end transaction model is simple, but if it's
demonstrably insufficient, I agree we should go for transaction ids.
That's orthogonal to the multiplexing of connections over a single
transport tho.
Rusty.
--
A bad analogy is like a leaky screwdriver -- Richard Braakman
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|