Hi Felix,
Felix Meschberger wrote:
Hi Erik,
Just a quick note, as Alex actually pretty completely responded.
>From your description, I assume, this is mostly a Jackrabbit/JCR issue.
So you might be better off asking on the jackrabbit dev (or user list),
where also the people implementing clustering are hanging around.
This was my initial thought, but it's not really a Jackrabbit issue,
since a pure Jackrabbit instance would have no problem doing this cast -
the problem is introduced in sling when using OSGi bundles. So maybe
more of a OSGi/Felix issue then?..
Inside Sling, we have additional Eventing Support which takes clustering
into account and which may help in ensuring, that only one node is
actually handling certain JCR events. This support implemented in the
extensions/event bundle replicates JCR events as OSGi events and is able
to ensure such translated events are only handled on a single node.
By "Inside Sling", do you mean internally - or something that can be
used by other bundles? If the latter is the case it sounds promising.
But how does this functionality tell if the JCR events are local or not?
Or does "certain JCR events" mean events triggered by Sling code - so
you can put extra information in it / on the node that triggers it?
But, as Alexander said, using the implementation class directly is not a
good idea: First it is not future-proof in terms of changes to the
Jackrabbit implementation. And secondly - much more important in terms
of OSGi - it locks you into a single use case and bundles.
I see that, so another solution would be preferable as long as we
reliably can get only one node to process the event without introducing
a single point of failure.
--
==================
Erik Buene
Senior Developer
Idium AS
