Marcel,
I register an EventListener at application startup, using the ObservationManager.addEventListener, using Event.PROPERTY_ADDED | Event.PROPERTY_CHANGED as the EventType. In the onEvent() method, I create an Event Handler with the Event as an argument, and it does the processing in a new thread: In the onEvent() method, I execute protected ExecutorService executor = Executors.newFixedThreadPool(NTHREDS); ... while (events.hasNext()) { ` Event event = events.nextEvent(); EventHandler handler = new EventHandler(event); executor.execute(handler); … } The EventHandler retrieves the node from the JCR Repository, evaluates the current state, and takes some actions depending on the state. One of them exports the node, etc. String path = event.getPath(); path = StringUtils.substringBeforeLast(path, "/“); T entity = service.getNode(path); … The service that is used to retrieve is nothing fancy, we’ve just wrapped the repository calls to support generics. In essence Session session = repository.login(credentials, null); Node node = session.getNode(path); session.logout(); … So, I change a String property of a node from “Draft” to “Approved”. Session session = repository.login(credentials, null); session.getWorkspace().getVersionManager().checkout(path); Node node = session.getNode(path); node.setProperty(“Status”,”Approved”); session.save(); session.getWorkspace().getVersionManager().checkin(path); The EventListener is notified, and the EventHandler is fired off. The node returned by the service layer does not always reflect the change. I haven’t been able to determine the circumstance, but on those occasions when the change is not reflected, the node’s “checkedOut” property is true, and the value of the property is whatever it was prior to the save. I’ve tried adding a loop in the EventHandler to retrieve the node, check the “checkedOut” property, sleep for 50 ms if it is true, etc. This seems to work, but there must be a better way. All of the events are local, so I’m not dealing with latency between separate instances. Any advice would be appreciated. Jim On 5/6/15, 3:01 AM, "Marcel Reutegger" <mreut...@adobe.com> wrote: >Hi Jim, > >can you please provide sample code, which shows the behaviour you >see? I'm particularly interested in what exactly you mean when >you write 'not always up-to-date'. > >Regards > Marcel > >On 05/05/15 21:16, "Jim.Tully" <jim.tu...@target.com> wrote: > >>Hi, >> >>We are using Oak in one of our applications, and have come up with a >>problem that I can¹t seem to find an answer to. >> >>We have an Event Listener registered to listen for changes to properties >>in a node. It is always notified of the events properly. Upon >>notification, the listener retrieves the Node from the session, and >>performs various actions depending on the properties set on the node. >> >>However, if the node is versioned, the node that is retrieved from the >>JCR is not always up-to-date, even if a new session is used to retrieve >>it. I assume that this is because versioning introduces a delay in the >>³save². Is there a way to work around this, short of forcing an >>arbitrary wait before attempting to retrieve the node? >> >>Thanks >> >>Jim