Hi On 10/25/2008 11:17 PM Gaetano Giunta wrote: > Tobias Schlitt a écrit : >> 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. > I have just given a short overview of the design document, sorry. > Focusing on your specific request: > - are orphan locks those that have been assigned to valid resources but > have expired, or are they resulting from other conditions? Yes, what I described as orphan locks are those, which are expired. The usual procedure of a client should be: 1. Lock desired resources 2. Perform operations 3. Unlock In case step 3 is not performed, the server needs to take care of cleaning the lock after a given timeout. This may happen, if a client crashes or the network connection breaks or similar. > - in the design doc, I see you state that the backend needs to be locked > completely, in case an If header occurs. can you elaborate a bit on that? The If header may contain lock tokens that refer to certain locks. Asumed that clients only send the If header when they make use of a lock, the backend needs to be locked to perform an atomic operation. In fact, this is only necessary if changes occur. Especially when it comes to shared locks (which we won't support, at least not now), backend locking is required anyway, since different clients may access the same WebDAV lock. > - the 3rd option to 'on every request' and 'on cronbjob execution' to > orphan lock purging is to adopt the php strategy, and define a > lp_probability and lp_divisor values that will trigger the purge obly > every now and then That'd mean we need to perform a complete purge over the backend in some requests, which will make a certain request really slow. I cannot see how this is more valueable here instead of purging via CRON. The backend would be locked while purging anyway, no matter how the purge is triggered. However, we can add this strategy later, when the purging API is once in place. 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
