Hi Alexander,
Thank you for taking time to reply.
Alexander Klimetschek wrote:
On Thu, May 29, 2008 at 12:49 PM, Erik Buene <[EMAIL PROTECTED]> wrote:
However our application requires some processing of events when nodes in the
repository changes - this processing will in turn perform other changes in
the repository. This should just be done by one node (the "local" node that
triggered the event).
You could run the event listener only on one node. To make a
distinction between the two instances, you could store some
information in the repository, so that only one node is actually
processing the data (something like event already handled).
But this would counteract the high availability aspect of clustering, as
it would introduce single point of failure on this node. I guess it
would be possible to set up hearbeat or some other way of telling if
other nodes are up and delegate the responsibility to take the task, but
it would really complicate the system.
This way
you have the same event listeners on both nodes, but only react on the
events on one node.
The problem with this approach is that events could be picked up at the
same time before repository synchronizes.
Sadly, the jcr Event interface does not have any method to determine if an
event is local or external - but it seems the Jackrabbit implementation
(org.apache.jackrabbit.core.observation.EventImpl) does.
You should avoid this. EventImpl might change and OSGi makes a clear
distinction between public API and implementation - it simply blocks
access completely. This might be inconvenient in some situations but
it makes the system future proof.
I understand that it would not be an ideal situation, but need a working
solution and haven't found a good one yet.
--
==================
Erik Buene
Senior Developer
Idium AS
