Hi Alex,
On 6/18/13 1:39 PM, "Alexander Klimetschek" <[email protected]> wrote: >The JCR spec mandates that an update after a session save() is >immediately visible to JCR queries after save() [0]. This is true for >normal property updates. So your code looks fine. > >The exception are full text index updates i.e. from binary files, which >are done asynchronously if they are too slow (> X ms I think), as the >full text extraction should not block things - it isn't something that a >programmatic query (that you might have directly after a session.save()) >could rely on anyway. > >[0] http://www.day.com/specs/jcr/2.0/6_Query.html#6.5%20Search%20Scope I thought about that, but that's not the problem here. It's really because of my wrong tampering with aggregate rules. The issue is solved for me. There was actually an inconsistency between the implementations of: - AggregateRule.getAggregateRoot() - AggregateRule.getAggregatedNodeStates() This lead to the differing behaviour, depending on the call trace, as there seems to be some subtle redundancy in Jackrabbit with respect to execution flows in that area. Just bad luck on my side :-) Thanks, Lukas
