Hi On 10/25/2008 09:51 PM Gaetano Giunta wrote: > Tobias Schlitt a écrit :
>> While working on the lock support I now dealt with purging of locks. >> This part looks to be quite complex and would need to be done on almost >> every request. It means very much overhead and IMO should not be done in >> request processing itself. >> >> I'd suggest to add a maintanance script to the Webdav component, which >> must be called by the administrator of the server periodically. The >> script locks the backend, goes through all locks and purges those that >> are orphan. >> > A bit offtopic for sure, but let me tell you the problems a happy > customer reported just a couple of days ago with the infamous ezp > session table: <snip /> > So, what is the moral of this long story ? That there is no free lunch. > Whatever scheme you pick, it will fail to scale in a given > configuration. And the worse is, if it is good enough, it will work > without a hitch until the scale is so big that the failure will be > massive (and unforeseen)! > Just do your very best to avoid locking up stuff as much as you can. Use > finer grained locks, read up on lockless algorithms, whatever. > And design the code in a way that both schemes can be adopted if the > need arises. Thanks for your comments. However, we don't have much freedom here, since the WebDAV RFC describes the rules for locking. It just leaves us with the choice to support locking or to leave it. Since some clients seem to require lock support (e.g. Finder), we need to support it. The locking described in the RFC is a complete mess (please refer to the design document I wrote about it for further details). I'm now in the choice of checking for orphan locks on every manipulation request (that is LOCK, PUT, DELTE, MKCOL, PROPPATCH) or to let the choice of when to check for orphan locks to the admin. I'm open for any other suggestion, but I think we should go for the described solution now to avoid time problems. We can still think of a different approach for this later, since the functionality will reside in its own classes and be independant from the rest. Regards, Toby -- Mit freundlichen Grüßen / Med vennlig hilsen / With kind regards Tobias Schlitt (GPG: 0xC462BC14) eZ Components Developer [EMAIL PROTECTED] | eZ Systems AS | ez.no -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
