我们有一个非常复杂的Java EE应用程序（Java后端+通过Spring HTTP Invoker进行通信的GRails前端），带有大量可怕的遗留代码。目前它在Jboss中运行（稍后将迁移到Tomcat）。
为了使其更可靠并提高性能，我们需要使其可以集群化。
问题是应用程序目前有很多深入的内存结构，对于需要复制的整个业务至关重要（比如另一个ConcurrentHashMap内部的ConcurrentHashMap里面的HashMap里面的域对象）。
正如我所说，有很多遗留代码，我们无法重做所有代码。
目前我正在使用EHCache，但显然没有成功 - 不会复制缓存对象内部的更改。
Terracotta DSO看起来像是我们应该研究的东西，但它是终极解决方案，我只是不想引入这种激进的解决方案，而我们希望以更一般的方式解决它。
答案 0 :(得分：1)
实际上这是大多数兑现解决方案的典型问题 - 使用深度内存结构并且没有简单的方法来解决这个问题。
例如，让我们采取企业网格 - gigaspaces - 这就是它的完成方式http://www.gigaspaces.com/wiki/display/XAP8/Modeling+your+data
这真的可以解释一下：
什么时候应该嵌入物体？ 您已经知道嵌入相关对象不是一个好习惯。但即使嵌入相关对象的情况很好（有时以数据重复为代价），您仍应注意以下事项：
嵌入意味着无法直接访问：当实体嵌入到另一个实体中时，您无法直接对其应用CRUD操作。相反，您需要通过regualr查询从空间获取其根父实体，然后向下导航对象图，直到获得所需的实体。这不仅仅是为了方便，还有性能影响：每当您想要在嵌入式实体上执行CRUD操作时，您首先读取整个图形并且（如果您还需要更新它），则将整个对象图形写回来到太空。 另一方面，GigaSpaces的非嵌入式关系意味着您需要在代码中自己管理关系。 用于选择嵌入式关系的Thumb规则 当实体仅对其包含对象的上下文有意义时嵌入。例如，在petclinic应用程序中 - 只有拥有所有者时，Pet才有意义。在这个特定的应用程序中，如果没有所有者，宠物本身就没有意义。将宠物从所有者转移到所有者或在没有所有者的情况下允许宠物进入兽医没有业务场景。 嵌入有时可能意味着重复您的数据。例如，如果您想从Pet和Vet类引用某个访问，则需要重复访问条目。那么让我们来看看重复： 复制意味着更喜欢可扩展性而不是占用空间 - 复制的原因是为了避免群集范围的事务，并且在许多情况下，它是以可伸缩的方式对对象进行分区的唯一方法。 复制意味着更高的内存消耗：虽然内存被认为是商品并且今天成本较低，但复制需要付出更大的代价 - 您可能有两个包含相同数据的空间对象。 重复意味着更宽松的一致性。例如，当您向Pet和Vet添加访问时，您需要同时更新它们。您可以在一个（可能是分布式的）事务中执行此操作，也可以在两个单独的事务中执行此操作，这些事务将扩展得更好，对于许多类型的应用（例如，社交网络）而言，这可能是足够的，其中丢失帖子虽然是不期望的，但不会引起显着的损害。相反，对于应考虑每项操作的金融应用来说，这是不可行的。
在 hazelcast 中，您有一个与gigaspace不同的数据关联http://www.hazelcast.com/docs/1.9.4/manual/multi_html/ch03.html概念。
我的意思是没有简单的解决方案，我想你无论如何都需要重新设计你的模型（无论这是一致性，gigaspaces，ehcache，hazelcast）。