Webdav client transactions

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

Hi,
 
I've been working with the webdav client transaction methods and wanted to
confirm something about their use and also potentially pass on some useful
information to others who intend to use them. The startTransaction and
endTransaction (the latter called by commitTransaction and abortTransaction)
methods lock the resource represented by the WebdavResource they are called
upon seemingly as a means of implementing transaction security. So when you
start a transaction with a webdav resource who's target is "/slide" you must
also call the commit and abort methods using the same path. If you don't
then the webdav client doesn't remove the transaction lock from its own lock
cache. And using the same resource for lock and unlock is exactly how it is
with the normal webdav client lock and unlock methods; but with the
transaction methods this is not immediately obvious as they don't take a
"target" parameter as lock and unlock do and the fact that they do lock and
unlock a resource to frame the transaction isn't common knowledge. I
discovered this because I have assigned one WebdavResource instance per
thread in my application and reuse these during the course of an application
request. To access another webdav resource I use the setPath() method to
change it to point to whatever resource I need at that time. But when I come
to commit or abort the transaction I needed to set the path of the
WebdavResource instance back to that I originally called startTransaction
with.
 
So, with all this, I'm now wondering if there is an optimal resource path
that I should use for the transaction lock? I just picked "/slide". But I
don't understand enough about what the transaction lock is to guess whether
this is a good or bad thing. Will having this resource locked during
transactions affect anyone else's attempts to lock this resource for general
CM purposes? Is the transaction lock even a normal lock in this regard? It
doesn't seem to be as it is treated differently by the server. If anyone can
shine some light on the design of the transaction locks I'd be interested to
know.
 
Thanks,
Warwick