jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fried <dfr...@phoenix-int.com>
Subject WebDAV servlets and locking
Date Thu, 23 Oct 2008 17:09:24 GMT

Here is what I know about the default Jackrabbit implementation of its WebDAV
* each HTTP request = one session
* therefore, session-scoped locks are useless, because locks effectively
disappear at the end of a LOCK request (the session is logged out) and both
the lock token and being in the same session are required to operate on a
locked resource
* many WebDAV client apps use session-scoped locks by default, meaning that
they will not work with Jackrabbit (at least out of the box)

I would like to user Jackrabbit as a repository, but I need something that
most existing WebDAV clients can interface with, and that includes being
able to lock files safely for periods of time.  From what I have read in the
list archives and what I have seen in the code, there are a few possible
solutions.  I'd like to hear the pros and cons of each solution, or if you
have any other ideas that may help.

Solution 1: HTTP session = session
Have one session for each authenticated WebDAV client which persists as long
as the HTTP session persists.  Since sessions are not guaranteed to be
thread-safe, I will need to synchronize requests at a relatively high level. 
Also, I will need a mechanism to expire dead sessions.  Evidently, there are
callbacks/listeners available for this.  This does seem like a relatively
low-impact solution because it only requires replacing/extending a session
factory class.  How feasible/usable is this solution?

Solution 2: authenticated user = session (/w timeout)
Same as above, but each user gets one session which is re-used until the
user is inactive for a bit (could use some kind of dynamic pool?).  This
will absolutely require synchronization of simultaneous requests, but...
whatever.  Maybe create different sessions for the same user with different
clients or IP addresses, just for safety's sake.

Solution 3: non-standard locks
Change the way locks work so that they can always be used if you have the
token, and make sure they time-out properly.  Maybe add the requirement that
you are the same user who created the lock.  This seems straightforward, but
also seems like it could horribly break a whole bunch of stuff under the
hood.  Am I right to be apprehensive?

Thanks in advance!

View this message in context: http://www.nabble.com/WebDAV-servlets-and-locking-tp20135445p20135445.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.

View raw message