Hi Alessandro, On 21/01/2008, Alessandro Bologna <[EMAIL PROTECTED]> wrote: > Now, after looking at the implementation, I actually wonder if the > locking approach would even work: is it guaranteed that if Server A > sees a new node in the Journal and locks it (with an open scoped lock) > another server B cannot lock it anymore? It seems to me that it really > depends on the read and lock operation being atomic, and I am afraid > it is not.
Yes, this is guaranteed: locking a node in a cluster consists of the following steps: 1) (exclusively) lock the journal 2) synchronize to the latest changes 3) write the (node) locking information to the journal 4) unlock the journal if Server A passes 1) first, Server B will be blocked in 1). After Server A has passed 4), Server B will execute 2) and will then see the changes made by Server A, which invalidates its own changes. Cheers Dominique > > Implementing an event queue, as suggested back then by Tobias, would > still present the same problem of locking the queue: unless there's > only one cluster node listening on that queue, how to prevent that > another may attempt (and possibly succeed) at locking the queue? > > Any hints on how to (efficiently) implement this? > > Thanks, > Alessandro >
