Subject: RE: Operations not Atomic (was: bind draft issues)

From: Jason Crawford <[email-masked]>
Date: Wed, 5 Mar 2003 19:31:29 -0500

> > For MOVE, I mostly mean the DELETE that occurs when the MOVE causes
> > an overwrite, although I could be convinced that ending up with 2
> > bindings to the collection in the event of an interrupted MOVE,
> > while inadvisable, shouldn't be prohibited.
>
> That's indeed a problem. All "overwrite" operations require a DELETE
(this
> also applies to BIND (!)), so having them atomic when the target is a
> collection has the same problems has the collection DELETE itself.

I am curious...

What does a system that doesn't support "atomic delete"
do in this situation if it gets stuck midway though the deallocation
portion
of the DELETE?   Does it leave the destination partially deleted and
abort the operation leaving it up the client to figure out what state this
was all left in?

------------------------------------------
Phone: 914-784-7569,   [email-masked]
I do not check [email-masked]

---

From: "Julian Reschke" <[email-masked]>
Date: Thu, 6 Mar 2003 08:20:43 +0100

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jason Crawford
> Sent: Thursday, March 06, 2003 1:31 AM
> To: Julian Reschke
> Cc: Brian Korver; WebDAV
> Subject: RE: Operations not Atomic (was: bind draft issues)
>
>
>
>
>
>
portion
> abort the operation leaving it up the client to figure out what state this

I think the answer is "yes". If the DELETE on the operation target isn't
atomic, I don't think there's any way to avoid this.

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: Taisuke Yamada <[email-masked]>
Date: Thu, 06 Mar 2003 18:25:41 +0900

>> (this also applies to BIND (!)), so having them atomic when the target
>> is a collection has the same problems has the collection DELETE itself.
>
> portion of the DELETE?

Why is "atomic DELETE" a problem? Couldn't it be implemented
just by simply moving resource out of current namespace?
My understanding is that any DELETE is just a MOVE to outerspace.

IMHO, you shouldn't really DELETE it before full COPY/MOVE/BIND
operation completes. If you do that, then you can't rollback
these operations in case of an interrupt (unless you keep DAV
resource content on RDB or something).

--
Taisuke Yamada <[email-masked]>
Internet Initiative Japan Inc., Technical Planning Division