[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: LCUP, persistent search
At 06:08 PM 3/15/2003, Howard Chu wrote:
>The uidNumber thread got me thinking about implementing mutexes from
>application level. Using modify to atomically toggle a lock attribute works,
>and multiple clients can wait on a lock using a persistent search to notify
>them when it's released. However, the waiting clients would then all be
>notified at once, and thrash the server while they try to acquire the lock.
>Is there a flag for the LCUP persistent search control to imply a round-robin
>style of service, i.e. if multiple clients have the same search outstanding,
>results will only be forwarded to one client at a time? Would it be worth
>suggesting?
>
>The other problem that this doesn't fix is, if the client currently holding
>the lock goes away, nobody else can acquire it. If the lock attribute was
>some kind of dynamic attribute instead, you could fix that too, automatically
>resetting it when the setting client connection closed.
I really don't think "locking" is the best answer to these
types of application needs. Instead, critical operations
(the read and the write, in this case) should be contained
within a transaction.
Kurt