java - 如何协调 J2EE 和 Java EE 数据库访问？

Question

我们有一个庞大的应用程序，它始于十年前，目前仍在积极开发中。所以一些部分仍然在 J2EE 1.4 架构中，其他部分使用 Java EE 5/6。

在测试一些新代码时，我意识到我在通过新旧代码部分传入的信息之间存在数据不一致，其中旧代码直接使用 Hibernate session ，而新代码使用注入(inject)的 EntityManager。这导致了一个问题，一个部分看不到另一部分的新数据，因此也创建了一条数据库记录，导致违反主键约束。

计划完全迁移旧代码以摆脱 J2EE，但与此同时 - 我可以做些什么来协调两个部分之间的数据库访问？在应用程序服务器中的某个时刻，两种方式不应该在 Hibernate 层中结合在一起，无论是通过 JPA 访问还是直接访问？

Answer 1

您可以在同一个应用程序中混合使用 Hibernate Session 和 Entity Manager，没有任何问题。 EntityManagerImpl简单地委托(delegate)调用私有(private) SessionImpl实例。

您描述的是事务配置异常。每个数据库事务都是独立运行的(除非你使用 REAN_UNCOMMITED，我想情况并非如此)，但是一旦你提交它，更改就可以从任何其他事务或连接中获得。因此，一旦提交事务，您应该会在任何其他 Hibernate session 、JDBC 连接甚至您的数据库 UI 管理器工具中看到所有更改。

你说的是主键冲突。如果您使用 Hibernate 标识或序列生成器，则不会发生这种情况。对于 old hi-lo generator如果外部连接试图在同一个表中插入记录，您可能会遇到问题 Hibernate 使用旧的 hi/lo 标识符生成器。

如果存在主/主复制异常，也会出现此问题。如果您有多个节点并且没有严格的一致性复制，您最终可能会违反主键约束。

更新

解决方案一:

当协调尝试插入同一实体的新旧代码时，您可以在 SERIALIZABLE 事务中运行一个 slect-than-insert 逻辑。 SERIALIZABLE 事务代表巡回获取适当的锁，因此您仍然可以拥有默认的 READ_COMMITTED 隔离级别，而只有有问题的服务方法被标记为 SERIALIZABLE。

所以旧代码和新代码都有这个逻辑运行一个select来检查是否已经有满足select约束的行，只有在没有找到的情况下才插入它。 SERIALIZABLE 隔离级别可以防止幻读，所以我认为它应该可以防止违反约束。

解决方案 2:

如果您愿意将此任务委派给 JDBC，您还可以调查 MERGE SQL statement ，如果您当前的数据库支持它。基本上，这是在幕后发出更新或插入的更新插入操作。这个命令更有吸引力，因为即使在 READ_COMMITTED 上你仍然可以运行它。唯一的缺点是你不能为它使用 Hibernate，只有一些数据库支持它。