jvm - Using Terracotta for (distributed) shared Java Objects

Question

How do you share an instance / object across different Java processes?

EnvironmentConfig config = new EnvironmentConfig();
config.setLogLockTimeout(3000);
config.setManagementEnabled(false);
config.setEnvCloseForcedly(true);
Environment env = Environments.newInstance(dbPath, config);
environmentMap.put(dbPath, env); 

It this code above, the Environment class is not Serializable and this object is used across the application process with:

Environment env = environmentMap.get(dbPath);

Then used like:

EntityId[] id = null; 
new PersistentEntityStoreBuilder(env).transact(txn -> {
    id[0] = txn.createEntity(comparableMap);
});
return id[0];

This Environment is the interface to the embedded database that is locked within the process that first accessed it. Meaning to say, other processes cannot access the database anymore thus in order for the other processes to access the database it needs the very same instance of the first Environment. That is where the "shared" Java object requirements roots.

Now I need to be able to use this same object (the Environment) across different application processes, I understand that this is not natively doable with the standard JVM, how would Terracotta be useful to handle such a requirement, I've been reading that Terracotta, in fact, can make multiple JVM processes act as one, so I thought that it might be the suitable solution.

The document states:

JVM-level clustering simplifies enterprise Java by enabling applications to be deployed on multiple JVMs, yet interact with each other as if they were running on the same JVM.

If this is not possible with Terracotta, can you explain why? If this is possible, how?

Answer 1

From reading a bit more of that document (which you could have done yourself), it looks like Terracotta is based on bytecode instrumentation and can in fact transparently share entire object graphs across JVMs running on separate machines.

So in principle it should work for you Environment class if it the "embedded database" behind it runs fully in memory and doesn't do anything crazy like using native code.

Whether it works in practice and especially what effect it will have on performance is something you'll just have to try out.