Hi Oliver, I implemented a finer lock mechanism. For our project we need only the plain WebDAV methods, so we do NOT use DeltaV versioning. This means all file requests go into /files. Knowing this I lock the URI parts either shared or exclusively depending on the kind of request.
Example: * GET on /files/col/file: shared on / shared on /files shared on /files/col shared on /files/col/file * PUT on /files/col/file shared on / shared on /files exclusive on /files/col (because the properties are written) exclusive on /files/col/file * DELETE on /files/col shared on / exclusive on /files (because the properties are written) exclusive on /files/col Database read committed. Connection pool as described in my other email today. Since then I did not have deadlocks any more, but several clients can work concurrently if they don't work inside the same collection. Without updating the lastmodified date of the collection it would not even be necessary to exclusively lock the collection (actually this is what we do, as lastmodified is defined by BINDING). This kind of lock granularity works for the plain WebDAV methods. So far I've never thought how this can work with DeltaV (everything in /history and /workspace and so on). I also did not think about the security stuff (/users), as we don't need this for our project (only one system user, no person). Maybe something similar to this could work out inspite of all the different operations which must be supported in general Slide. Perhaps I could even contribute some code if this would help, but before that I need to check this with my employer... Regards, Andreas On 27 Jul 2004 at 13:39, Oliver Zeigermann wrote: > I have just done something really bad and am pretty sure it will be hard > to get a new job if I never need one ;) > > I have introduced a global read/write lock that can be configured to > allow at most a single write request per time. It can also be configured > to either allow read requests or disallow them while another request > writes. However, this switch will have no effect when requests are done > inside external transactions. > > No more deadlocks or failed uploads could be observed with that switch. > Also no starvations of requests... I will make it the default in Domain.xml. > > While it may look like I am a complete idiot and all my work on TLocks > and Sequences were in vain, they will become more useful in the future > with a real concurrent Slide kernel. For now, they will at least be > useful in externally controlled transactions. > > Oliver > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
