Next message: Geoffrey M. Clemm: "Re: Sharing version selectors [was Re: Comments on draft-ietf-deltav-versioning-08]"
Date: Mon, 25 Sep 2000 14:14:36 -0400 (EDT)
Message-Id: <200009251814.OAA24754@tantalum.atria.com>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
Subject: Re: BATCH operation [was Re: Comments on draft-ietf-deltav-versioning-08]
From: Ross Wetmore <rwetmore@verticalsky.com>
I do not believe a BATCHed atomic operation is anymore limited to
sophisticated database systems than the current set of operations
are, or at least that was not the connotation I had intended, i.e. the
extreme case. I would not like to see this used as a cop-out to avoid
the issue of how to deal with compound operations on the server as
opposed to from the client.
It's important to identify what kind of batching operation
you have in mind. Is it an "atomic" batching operation
(that guarantees all operations will be performed atomically, or not
at all), an "exclusive" batching operation (that guarantees that
no other client will change the state in the middle of the batch of
operations), both, or neither?
If it's an atomic batching operation, that's where you need a
database system (file system implementations, for example, will
not provide atomic batching behavior).
If it's exclusive batching operation, then it is very hard to
avoid denial of service attacks (everyone else is locked out while
your long compound operation is being performed).
If it is neither, then you it certainly can be defined, but you do
have to decide what the behavior is if any of the intermediate steps
fail. (Keep going, stop, some kind of conditional behavior?). You
then need to pass back some idea of what steps succeeded, and if you
keep going over failure, what the status was of each of the steps.
This is all doable, but you need to avoid designing a whole programming
language in the process (:-).
The point I wished to make is that WebDAV versioning extensions have
broken down execution into what is perceived to be an elementary set
of primitive operations. But most versioning systems implement implement
user operations that are a combination of several primitives.
To get interoperable atomic behavior, since most versioning systems
don't support user-defined atomic batching behavior, you are pretty
much forced to stay at the primitive level. In particular, if one
system allows you to combine the operations X and Y into an atomic
compound operation X-Y and another system allows you to combine the
operations Y and Z into an atomic compound operation Y-Z, then the
only atomic behavior a client can use for both systems is X, Y, and Z,
as separate atomic operations.
To try
and handle the typical situation in any reasonably sophisticated
versioning system, or even one that is not quite aligned to the underlying
model being developed here, some mechanism is needed to move some of the
logic for conditionally executing a set of operations to the server as a
single network transaction. Leaving the onus of dealing with these
issues solely to the client to be run over a slow, potentially flaky
network may severely impact the utility and capability of the WebDAV
extensions.
It sounds here like you are just trying to avoid network overhead
(i.e. you can live without atomic or exclusive behavior from the
batching operation).
If I used the term "server BATCH scripting capability" to describe
the concept, with only a couple of simple server operations defined for
a starter, rather than a full-blown multi-threaded atomic execution
engine, would this help move the discussion forward?
A simple non-atomic, non-exclusive batching operation could certainly
be defined (I believe), but it is orthogonal to "versioning", so I
wouldn't want to delay the versioning protocol to define the
batching protocol. Experience from the batching discussions from
the WebDAV protocol indicates that this is not something that is
easy to get closure on.
In its simplest form this might simply be the ability to nest successive
operations. An error return from any nested operation would be treated
as an error in the post-condition of the preceding operation, and cause
whatever rollback was appropriate for that operation.
It's the "cause whatever rollback was appropriate" that would be
problematic. For example, many versioning systems do not allow you to
delete versions once they have been created. In addition, unless you
reserved the versioning repository for the duration of the compound
request (which doesn't scale to supporting dozens or hundreds of users
trying to access a shared repository), or unless you have a
sophisticated database repository that allows rollback of compound
operations, other requests will have been executed that took
advantage of your partial results, and those couldn't be rolled back.
Cheers,
Geoff