我们有一个 J2EE 应用程序，我们仍在开发中。它运行在 Oracle 数据库上。业务层使用 EJB 2.0 编码，具有丰富的客户端接口(interface)。
现在，该应用程序将部署在多个站点上。每个站点都将创建新项目(新契约(Contract)等)。
我们想要实现的是使用与本地相同的数据库架构复制所有添加到中央位置数据库的新项目。
您认为实现这一目标的最有效方法是什么？
我考虑过序列化所有创建的新项目并将它们发送到远程站点以通过 Java 消息服务队列进行集成。这种方法好吗？
并且还会有一些更改被复制回卫星。
最佳答案
我会说与中心的同步关系会引入您不想要的耦合。因此，您的异步想法对我来说似乎很不错。您可能在记录中有一些与位置相关的标识符，这样在不同位置创建的新契约(Contract)就不会发生冲突，并且您接受复制到中心的一些延迟。
所以简单的情况是只使用从每个位置到中心的 JMS 消息。
这种方法的好处是卫星甚至不需要知道中心的数据库结构，它可以完全独立地设计。
如果您还需要将更改从中心复制回卫星，事情就会变得更加有趣。最大的问题是我们是否会在中心的变化和卫星的变化之间发生冲突。
简单情况:任何数据项都有一个“家”。例如，原始卫星是进行更改的地方。或者在创建之后，中心是唯一可以进行更改的地方。在这种情况下，我们可以将中心视为“中心”，它可以将更改传播到卫星。简单的 JMS 就可以做到这一点。
稍微困难一点的情况:可以在任何地方进行更改，但一次只能在一个地方进行。因此我们可以引入某种类型的锁定方案。我倾向于让中心成为所有者，并使用同步网络服务来锁定和更新数据。现在我们已经结合了，但如果我们要有一个明确的所有者，那是必要的。
相当复杂的情况:任何人都可以在任何地方更改任何内容而无需锁定。这是一种“先行动，后道歉”的方法。我们采取乐观的态度，认为变化不会发生冲突。我们可以将更改发送到中心进行审批，中心可以使用乐观锁定或合并非冲突更改方法。我倾向于通过排队更改发起者来做到这一点，但实际上是通过同步调用来处理它们。因此，将变更规范与中心的可用性分离开来。一些更复杂的数据库具有差异/合并功能，可能有助于解决此问题。
大问题是您希望在多大程度上与中心的可用性相关联，以及发生冲突变化的可能性。巧妙的应用程序设计通常可以大大降低发生冲突的可能性。
关于java - 在 j2ee 应用程序中的站点之间复制数据，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1635849/