Observation and locking of events in cluster

[Alessandro Bologna <al...@gmail.com>]

A while ago, there was a request to add a feature in the Jackrabbit
clustering implementation: to be able to tell if an event has been
processed already by another node participating in the cluster.

The obvious use case is that of a producer and many consumers, with
the producer generating lots of new set of nodes and the consumers
rendering them. Assuming that rendering may be a cpu intensive
operation, there would be a clear advantage if the load could be
spread.

Back then I thought it was not so needed, because the item associated
with the event could have been locked by the first observer that sees
it, so that any other listener would just ignore the event and move on
to the next.
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.

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

Re: Observation and locking of events in cluster

[Dominique Pfister <do...@day.com>]

Hi Alessandro,

On 21/01/2008, Alessandro Bologna <al...@gmail.com> 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
>