We're using slide (actually tamino - but this is presumably a bug in the slide layers) with auto-versioning turned on, in "checkin-unlocked-checkout" mode. We recently noticed a bug which causes resources to get 'stuck' checked-out (since we are using autoversioning, there's no explicit checkin or checkout requests).
The normal sequence of events is: LOCK PUT (1 or more times) UNLOCK
Now, suppose the program in use crashes (or loses network connectivity, or whatever) after the first two stages here. The resource is checked-out (by the auto-versioning code) and locked (by the LOCK request). At some point, the lock expires, and the lock is removed by slide (I think this happens somewhere in the slide core). However, it's still checked-out - this implicit unlock (due to the lock timeout) does not cause the checkin request. The spec (3.2, paragraph 5) explicitly notes that a lock timeout should be treated the same as an UNLOCK request in this case.
I imagine (but I don't know my way around the deltav code in slide) that this happens because most of deltav is implemented in the webdav layer, but lock timeouts are handled in the core (I may be wrong in this too, of course...), and the core has no way of calling back out to the webdav/deltav layer to handle this case.
Any suggestions? Workarounds? Better yet, fixes? ;-)
Mike
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
