英文:
Using Terracotta for (distributed) shared Java Objects
问题
如何在不同的Java进程之间共享一个实例/对象？
在上面的代码中，Environment类不是可序列化的，而且这个对象在整个应用程序进程中被使用，例如：
Environment env = environmentMap.get(dbPath);
然后像这样使用它：
EntityId[] id = null;
new PersistentEntityStoreBuilder(env).transact(txn -> {
id[0] = txn.createEntity(comparableMap);
});
return id[0];
这个Environment是嵌入式数据库的接口，它在首次访问它的进程中被锁定。也就是说，其他进程无法再访问数据库，因此为了让其他进程能够访问数据库，它需要第一个Environment的相同实例。这就是"共享"Java对象的需求来源。
现在我需要能够在不同的应用程序进程中使用这个相同的对象（Environment），我理解使用标准的JVM本身无法直接做到这一点，Terracotta如何处理这样的需求？我一直在阅读Terracotta的资料，事实上，Terracotta可以使多个JVM进程像一个进程一样运行，所以我认为它可能是合适的解决方案。
文档中提到：
JVM级别的集群化通过允许应用程序在多个JVM上部署，但可以像在同一个JVM上运行时那样相互交互，从而简化了企业Java。
如果Terracotta不能实现这一点，您能解释为什么吗？如果可以实现，具体如何实现呢？
英文:
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?
答案1
得分: 2
从阅读该文件的更多内容（你本可以自己阅读），看起来Terracotta基于字节码插装，实际上可以在运行在不同机器上的JVM之间透明地共享整个对象图。
所以，原则上，如果它背后的“嵌入式数据库”完全在内存中运行，并且不做任何像使用本机代码之类的疯狂事情，它应该可以适用于你的Environment类。
它是否在实践中起作用，特别是对性能产生什么影响，这是你只能尝试一下的事情。
英文:
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.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论