Usando Terracotta para objetos Java compartilhados (distribuídos)

Question

Como você compartilha uma instância / objeto entre diferentes processos Java?

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

Neste código acima, a Environmentclasse não é Serializablee este objeto é usado em todo o processo de aplicação com:

Environment env = environmentMap.get(dbPath);

Então usado como:

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

Esta Environmenté a interface para o banco de dados embutido que está bloqueado no processo que o acessou primeiro. Ou seja, outros processos não podem mais acessar o banco de dados, portanto, para que os outros processos acessem o banco de dados ele precisa da mesma instância do primeiro Ambiente. É aí que se originam os requisitos do objeto Java "compartilhado".

Agora eu preciso ser capaz de usar este mesmo objeto (o ambiente ) em diferentes processos de aplicativos, eu entendo que isso não é nativamente viável com a JVM padrão, como o Terracotta seria útil para lidar com tal requisito, tenho lido que O Terracotta, na verdade, pode fazer com que vários processos JVM funcionem como um, então pensei que poderia ser a solução adequada.

O documento afirma:

O armazenamento em cluster no nível de JVM simplifica o Java corporativo, permitindo que aplicativos sejam implementados em várias JVMs, mas interajam entre si como se estivessem em execução na mesma JVM.

Se isso não é possível com Terracota, você pode explicar por quê? Se isso for possível, como?

Answer 1

Ao ler um pouco mais desse documento (o que você mesmo poderia ter feito), parece que o Terracotta é baseado na instrumentação de bytecode e pode, de fato, compartilhar de forma transparente gráficos de objetos inteiros em JVMs em execução em máquinas separadas.

Portanto, em princípio, ele deve funcionar para sua classe de ambiente se o "banco de dados embutido" por trás dele for executado totalmente na memória e não fizer nada louco como usar código nativo.

Se funciona na prática e especialmente o efeito que terá no desempenho, é algo que você apenas terá que experimentar.