Uso de Terracotta para objetos Java compartidos (distribuidos)

Question

¿Cómo se comparte una instancia / objeto en diferentes procesos de Java?

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

En este código anterior, la Environmentclase no lo es Serializabley este objeto se usa en todo el proceso de aplicación con:

Environment env = environmentMap.get(dbPath);

Luego se usa como:

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

Esta Environmentes la interfaz de la base de datos incorporada que está bloqueada dentro del proceso que primero accedió a ella. Es decir, otros procesos ya no pueden acceder a la base de datos, por lo tanto, para que los otros procesos accedan a la base de datos, necesita la misma instancia del primer entorno. Ahí es donde radican los requisitos de los objetos Java "compartidos".

Ahora necesito poder usar este mismo objeto (el Entorno ) en diferentes procesos de aplicación, entiendo que esto no se puede hacer de forma nativa con la JVM estándar, ¿cómo sería útil Terracotta para manejar tal requisito? He estado leyendo eso Terracotta, de hecho, puede hacer que múltiples procesos JVM actúen como uno solo, así que pensé que podría ser la solución adecuada.

El documento dice:

La agrupación en clústeres a nivel de JVM simplifica Java empresarial al permitir que las aplicaciones se implementen en múltiples JVM, pero que interactúen entre sí como si estuvieran ejecutándose en la misma JVM.

Si esto no es posible con Terracotta, ¿puede explicar por qué? Si esto es posible, ¿cómo?

Answer 1

Después de leer un poco más de ese documento (que podría haber hecho usted mismo), parece que Terracotta se basa en instrumentación de código de bytes y, de hecho, puede compartir de forma transparente gráficos de objetos completos en JVM que se ejecutan en máquinas separadas.

Entonces, en principio , debería funcionar para su clase de entorno si la "base de datos incorporada" detrás de ella se ejecuta completamente en la memoria y no hace nada loco como usar código nativo.

Si funciona en la práctica y, especialmente, qué efecto tendrá en el rendimiento, es algo que tendrá que probar.