|[CDO] How do Passive updates work ? [message #1695074]
||Mon, 11 May 2015 20:09
| Stephane Fournier
Registered: July 2009
I would like to get some more detailed explanations about Passive Updates.
Let me introduce a brief use case:
- 2 client JVM (A, B running on different computers) connected to a same CDO server (running on another computer) accessing a resource containing data based on the famous Company ecore model.
- Let's say that JVM A, on computer "One", commits the fact a new Employee is created and added in a containment relationship of a company. After the transaction commit operation call, JVM A uses RMI to remotely calls JVM B (in RMI threads) passing the name of the employee (for instance).
- On JVM B side, RMI implementation tries to lookup the Employee from its name.
Depending on how the Passive updates are quick or not, JVM B find or not the previously added Employee. Indeed, RMI call handling is done in another thread, and on JVM B side, it might happen the update of the CDO transaction happens after the RMI call.
If I add a sleep of 200ms after the commit operation and before the RMI call, I never faced the issue. But usage of sleep() is not a proper solution always difficult to find the right value.
It seems to me, Passive updates, to call back remote clients, are NOT done during the commit itself, but in reaction of the end of the commit on server side.
Is it right ?
To recap : when client A calls transaction.commit(); and commit() steps out, we cannot make sure other remote clients are up-to-date immediately (even with passive update set to true) ?
If'm right, how can I make sure when I commit something in CDO every remote clients are up-to-date ?
I perfectly know I can register listener (CDO ones or EMF adapters) on the model stored in the server to be notified, but for other reasons I need to use RMI and pass attribute values to identify objects to lookup on other side.
Does anyone have an idea how to solve that integration (between RMI and CDO) issue ?
Thanks in adavance,
Powered by FUDForum
. Page generated in 0.02258 seconds