RE: Comments on 06 spec

Surendra,

On Friday, January 23, 1998 3:01 PM, Surendra Reddy 
[SMTP:SKREDDY@us.oracle.com] wrote:
>    Jim/Judith,
>
>
>     I am little bit confused with COPY, MOVE and DELETE operations.
>
>     I have gone through the scenarios document, and protocol document. I
> would appreciate if someone can explain to me
>     how the following scenarios are handled using the current protocol 
spec.
> I am not trying to take whole group
>     back to use case analysis stage, but, my objective here is to make 
sure
> that current protocol has all definitions and
>     explanations to have a clean implementation. Otherwise, to overcome 
some
> of the limitation each implementor will choose
>    their own way of interpretion and which lead to interoperability 
issues.

Judging by the discussion this has started, this is a worthwhile activity.

>     Scenario A:	Jane directs that the page P and all subordinate objects 
be
> deleted from the web W.
> 		Joe directs his web browser to retrieve page P from the web W.
>
> 		Issue here is: If deletion of page P and associated subordinate objects
> from the Web W
> 		takes sometime to process, then Joe requests this page and by that time
> some references
> 		to that page might have deleted already and hence joe sees broken links 
on
> page P. This throws an
> 		integrity issue.

There are at least two possible ways of handling this situation, and both 
are completely acceptable (intentionally so) according to the current 
language in the -06 spec.  These two situations correspond to the two 
different types of servers in Mark Fisher's post (database and "freeware")

a) ("freeware") The server happily returns page P to Joe, and page P may 
very well contain broken links.  As both Jim Davis and Mark fisher have 
pointed out, the web is optimized for distribution and availability, so 
this choice is consistent with the design principles of the web.

b) (database) A smarter web server might note that P's namespace is being 
deleted, and prevent accesses to this namespace while the operation is 
taking place.

Again, both are legal.  The advantage of this is that a DAV server 
implemented on a file system doesn't have to use an internal transaction 
manager, while a DAV server implemented on a database or a document 
management system can be much more intelligent by making use of its native 
capabilities.

> Or in other case, assume joe had already started editing
> this page P. Jane deleted
> 		this and when joe gets into publishing stage there is no matching
> properties associated with the same
> 		document.

If Joe is editing page P without having first taken out a lock, then it is 
acceptable to Joe to have P change while he is editing it.  If it is 
unacceptable to Joe that P change while he is editing it, then Joe must 
take out a write lock prior to starting his edit session.

>    Scenario B:     Jane directs that collection C be moved to collection 
D.
> While this move
> 		operation in progress. joe directs his editor to take a 
write(exclusive)
> lock on Collection D.
> 		This request will succeed as MOVE operation hasn't taken any explicit 
lock
> on Collection D.
> 		If this assumption is right, then, rest of the move operation will fail 
as
> EXCLUSIVE WRITE lock has acquired
> 		by joe on collection D and jane cannot be completed either server will 
be
> WAITING for lock release
> 		on collection D.

There are many cases here:
1) If Joe's lock on D is processed before Jane's MOVE operation, the MOVE 
will fail.
2) One server strategy is to pause operations on D while the MOVE was 
taking place.  In this case, the MOVE would finish, then the lock operation 
would be performed.
3) Another strategy is to allow the operations to interleave, allowing the 
MOVE to start, and then, while the MOVE is underway, start performing the 
LOCK.  Even if the MOVE does not MOVE all members of the source collection 
to the destination, the semantics of MOVE are such that a partial failure 
does not result in a rollback on failure, so it is OK to interleave without 
knowing the final outcome.

>    I think, to make the spec more clearer, good add some more explanation 
on
> COPY, MOVE and DELETE methods, how
>    locks are issued on source and target resources for these operations 
and
> impact of this on relevant methods.

I agree, a small section on the integrity concerns is probably worthwhile. 
 On the other hand, describing all of the possible interactions between all 
methods is a combinatoric nightmare, and I think this isn't a good idea.

- Jim

Received on Monday, 26 January 1998 16:52:28 UTC