On 2012-02-06 21:01, Ingomar Otter wrote:
> Hello,
> I am currently building a simple replication between two Jackrabbit instances. I've started
off using (synchronous) Observers/Events but I am facing some challenges due to
> the (intresting?) event order.
> E.g. I add a file (using webdav) I see the following events (in that order):
>> PROPERTY_ADDED,2@4376: /Somefile.png/jcr:content/jcr:data
>> PROPERTY_ADDED,1@4377: /Somefile.png/jcr:content/jcr:mimeType
>> PROPERTY_ADDED,7@4378: /Somefile.png/jcr:content/jcr:primaryType
>> PROPERTY_ADDED,5@4379: /Somefile.png/jcr:content/jcr:lastModified
>> PROPERTY_ADDED,5@4380: /Somefile.png/jcr:created
>> NODE_ADDED@4381: /Somefile.png/jcr:content
>> PROPERTY_ADDED,1@4382: /Somefile.png/jcr:createdBy
>> PROPERTY_ADDED,7@4383: /Somefile.png/jcr:primaryType
>> NODE_ADDED@4384 :/Somefile.png
>
>
> Of course I can not replay the events in that order as some parent nodes may be missing.
I could re-order them but then this would at least require some "unit of work" demarcation
as I operate on stream of events (and thus need to cluster/chunk) the events.
> Is there a reason why the events are emitted in 'reverse' order (I would assume per API
the node was created first)?
> Is there a way to influence this?
>
> Afaik PERSIST (event bundling) is work-in-progress in unstable, would that be a candidate
as Unit-Of-Work marker?
In the meantime I realized that PERSIST events are not in 2.4.0 (but
probably could be ported), and also that you may not need them; they are
only needed and present in Journaled observation -- are you using that?
Best regards, Julian
|