Tobias Schlitt a écrit : > 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. > 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? - 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 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
bye Gaetano -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
