|Cache Coordination Architecture (RMI & multicast) [message #503031]
||Thu, 10 December 2009 16:07
Registered: December 2009
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,
Powered by FUDForum
. Page generated in 0.01531 seconds