[dev] Fwd: Re: Horde Lock

[Ben Klang]

On May 16, 2008, at 12:11 PM, duck wrote:

> On Wed, 2008-05-14 at 17:35 -0400, Ben Klang wrote:
>> It all seems reasonable to me.  I'll look at implementing the
>> addition of lock scope.
>>
>> /BAK/
>
> Maybe an function like Horde_Lock::isLocked($principal, $scope, $type,
> $ignore_current) will be useful to. Instead of a selecting all rows  
> with
> getLocks() we just COUNT or better select “1” with limit on “0,1”  
> to see
> if the requested resource is locked or not. And an option to ignore
> locks from current user must be added to. Who cares if the resource is
> locked by ourselfs.
A session should already know/keep track of its own locks.  If it  
can't do that then those locks should be considered abandoned.  I'm  
not sure I'm comfortable with excluding locks in place by the current  
user because it is possible for a single user account to be logged in  
multiple times with a separate set of locks (ie. a shared account or  
even a really zealous user).

>
>
> And I will add an option to clear a lock by attributes too, again to
> avoid not needed additional queries and simpler implementation.
Can you give me an example of what you're talking about here?

>
>
> PS. Index on columns for used in where are missing in the sql script.

I'm expecting the typical use case will create a lock for a  
relatively short duration, say less than 10 minutes.  In that case  
are you really going to have enough users reading the locks often  
enough to get a benefit from that?  How many locks are you expecting  
to grant?  While I am not opposed to adding an index where it makes  
sense I'm not wanting to go around adding indices for the sake of  
having an index for every single WHERE clause.

/BAK/
-- 
Ben Klang
Alkaloid Networks LLC
ben at alkaloid.net
404.475.4850
http://projects.alkaloid.net