Skip to main content

Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » EclipseLink » Cache Coordination Architecture (RMI & multicast)
Cache Coordination Architecture (RMI & multicast) [message #503031] Thu, 10 December 2009 16:07 Go to next message
Jethrie  is currently offline Jethrie Friend
Messages: 2
Registered: December 2009
Junior Member

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,

Re: Cache Coordination Architecture (RMI & multicast) [message #503738 is a reply to message #503031] Tue, 15 December 2009 10:10 Go to previous message
James Sutherland is currently offline James SutherlandFriend
Messages: 1939
Registered: July 2009
Location: Ottawa, Canada
Senior Member

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
Previous Topic:Exception while using static weaving
Next Topic:1.1.3 vs 2.0 equals
Goto Forum:

Current Time: Sat Jun 23 06:26:21 GMT 2018

Powered by FUDForum. Page generated in 0.01502 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top