Hi Jim, it would be best if you can come up with a test to reproduce the behavior you described.
it is not clear to me what exactly the EventHandler does. AFAIU you create an EventHandler for each modification on that node. this means, in your example when the node transitions from 'Draft' to 'Approved', three EventHandlers will get created. the first for the checkout() operation, a second for the update on the 'Status' property and a third for the checkin(). how do you know you are dealing with the second one and not the first? Regards Marcel On 06/05/15 17:14, "Jim.Tully" <[email protected]> wrote: >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" <[email protected]> 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" <[email protected]> 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 >
