| Cache Coordination Architecture (RMI & multicast) [message #503031] |
Thu, 10 December 2009 16:07  |
 Jethrie 
Messages: 2
Registered: December 2009 |
Junior Member |
|
|
Hello,
I have read this page about cache coordination in EclipseLink, and what I seem to understand is that this is a 2-steps process:
- When a session "starts", it adds itslef in a registry and broadcasts an announcement that will enable interested session to locate the new session, ending up in all sessions being bidirectionally linked
- Then a session, quoting the doc, can "start sending and receiving object change messages"
1) Why is the registry necessary? Couldn't the session directly propagate a serialized RMI stub in the announcement packet?
2) I take it from this that at runtime, when an update is performed, the session which initially performs the change will call (as an RMI client) all other sessions (acting as RMI servers) to synchronously invoke some sort of "applyChange" method.
So the overhead, in terms of response time, grows linearly with the size of the cluster, right?
3) I understand that RMI Cache Coordination involves, by definition, well, RMI, but why isn't there a full-multicast cache coordination mechanism, where all "object changes" would be broadcasted in multicast packets? Of course there's a long way towards making it reliable and synchronous, it would probably be asynchronous...
4) Indeed I saw this post, and assumed from it that TopLink used to support a full-multicast cache coordination. Is there any plan to support it in EclipseLink too?
Thank you in advance, and best regards,
J.
|
|
|
| Re: Cache Coordination Architecture (RMI & multicast) [message #503738 is a reply to message #503031] |
Tue, 15 December 2009 10:10  |
|
1) Both RMI registry and JNDI are supported.
2) More or less correct. With RMI both synchronous and asynchronous are supported. We also support JMS, which offers are large range of different products, with differing configurations and scalability factors.
3/4) We are not interested in building a communications service, so instead integrate with the JMS standard which offers a wide range of different products and implementations.
There are other standards such as JGroups. We used to support an OC4J JGroups integration in TopLink, but this was not carried over to EclipseLink because of its OC4J dependencies. I agree that JGroups support would be desirable, please log an enhancement request for this if one does not already exist, if one exists please vote for it.
As part of the Oracle TopLink product which uses EclipseLink a cache integration with Oracle Coherence is supported. This offers several other distributed caching options.
James : Wiki : Book : Blog : Twitter
|
|
|
Powered by
FUDForum. Page generated in 0.03058 seconds
] 
Search
Help
Register
Login
Home
