Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I'd be curious to know more about your requirements. As another answer suggests, Terracotta may be exactly what you are looking for.</p> <p>There is a subtle difference however between what Terracotta provides, and what you are asking for, thus my inquiry.</p> <p>The difference is that as far as you are concerned, Terracotta does not provide "remote" references to objects - in fact the whole "remote" notion of RMI, JMS, etc. is entirely absent when using Terracotta.</p> <p>Rather, in Terracotta, all objects reside in large virtual heap. Threads, whether on Node 1, or Node 2, Node 3, Node 4, etc all have access to any object in the virtual heap.</p> <p>There's no special programming to learn, or special APIs, objects in the "virtual" heap have exactly the same behavior as objects in the local heap. </p> <p>In short, what Terracotta provides is a programming model for multiple JVMs that operates exactly the same as a the programming model for a single JVM. Threads in separate nodes simply behave like threads in a single node - object mutations, synchronized, wait, notify all behave exactly the same across nodes as as across threads - there's no difference.</p> <p>Furthermore, unlike any solution to come before it, object references are maintained across nodes - meaning you can use ==. It's all a part of maintaining the Java Memory Model across the cluster which is the fundamental requirement to make "regular" Java (e.g. POJOs, synchronized, wait/notify) work (none of that works if you don't / can't preserve object identity across the cluster).</p> <p>So the question comes back to you to further refine your requiements - for what purpose do you need "remote" pointers?</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload