A few webdav client locking concerns

[Warwick Burrows <wa...@e2open.com>]

Hi,
 
I'm running into some more client-transaction problems and have been looking
at the webdav client. I've noticed a couple of issues and want to air them
to see if anyone familiar with the DAV spec locking agrees or disagrees with
what I see:
 
1. Is it valid in the spec for a list of locks to be passed in the "if"
header to the server for a LOCK and UNLOCK operation? By calling
generateIfHeader() from LockMethod and UnlockMethod its putting lock tokens
in the "if" header when the target lock token is already being specified
with the "lock-token" header. Now the format for refreshing a lock using the
LOCK request has an "if" header only and no "lock-token". Meanwhile the lock
request has a "lock-token" but no "if" headers. The client seems to be
sending both on every request. The server just ignores them and only assumes
a refresh when there is no body for the request which is valid but
generating the "if" headers when they aren't needed would be misleading and
wasteful.
 
2. The getAllLocks(path) method of the WebdavState class takes a path for
which I gather it is supposed to return the set of locks that pertain to
that path. Within the method though it returns all of the locks that the
client currently knows about. That would be fine if each WebdavResource is
used only to lock and unlock the object represented by that resource but if
you use any of the methods that take a pathname for the target to lock then
the client's lock cache will now also include the list of locks that have
been created for any of those targets. You can imagine that with a config
like I have, which is to use one WebdavResource per thread to keep the
number of connections to the server down and reuse the http and webdav
client state, that there can be locks for other resources in the cache of an
individual client instance.
 
3. If getAllLocks() was changed to return locks for a particular path, is
there a reason that the client would need to send a list of locks for the
resource in the "if" header for a particular request? Even if the lock can
be shared and there are other users locks in the client lock cache, the
method is being performed only for the current owner. It seems like
getAllLocks() should also take the owner for whom you want to fetch locks
and restrict "if" headers to one token. Except for the LockMethod in which
case I gather that you can refresh multiple locks at once??
 
4. Transaction locks are being stored alongside normal locks. ie. the locks
that are created using startTransaction() and endTransaction() are kept in
the same client lock cache as other locks which is what spurred my questions
above. The getAllLocks() function is returning this special lock and adding
it to every "if" header sent to the server. But this may only be a problem
because the processing of transaction locks is handled alongside every other
lock in the parseResponse*() methods of the LockMethod/UnlockMethod. Seeing
that the call to LockMethod made from the startTransaction() method doesn't
add the lock to the client lock cache with addLock() like the lockMethods()
do and the lock token is in fact kept in a "transactionHandle" variable used
exclusively to generate the transaction header, I believe that the
transaction locks shouldn't be stored in the client cache with other locks.
Otherwise they will show up as normal locks when they are actually
implemented internally by the slide server.
 
Warwick
 

Re: A few webdav client locking concerns

[Oliver Zeigermann <ol...@gmail.com>]

On Mon, 13 Dec 2004 16:49:11 -0800, Warwick Burrows
<wa...@e2open.com> wrote:
> 4. Transaction locks are being stored alongside normal locks. ie. the locks
> that are created using startTransaction() and endTransaction() are kept in
> the same client lock cache as other locks which is what spurred my questions

There should  be no locks created by startTransaction() and
endTransaction(). Or are you talking about the locks created inside
the transaction?

> above. The getAllLocks() function is returning this special lock and adding
> it to every "if" header sent to the server. But this may only be a problem
> because the processing of transaction locks is handled alongside every other
> lock in the parseResponse*() methods of the LockMethod/UnlockMethod. Seeing
> that the call to LockMethod made from the startTransaction() method doesn't
> add the lock to the client lock cache with addLock() like the lockMethods()
> do and the lock token is in fact kept in a "transactionHandle" variable used
> exclusively to generate the transaction header, I believe that the
> transaction locks shouldn't be stored in the client cache with other locks.

What transaction locks? The transactional control only "misuses" the
LOCK/UNLOCK method to actually start/end a transaction. No locks are
involved...

> Otherwise they will show up as normal locks when they are actually
> implemented internally by the slide server.

???

Oliver

---------------------------------------------------------------------
To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-user-help@jakarta.apache.org