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
