6

我们有一个使用 JUnit、OpenEJB、Eclipselink 和 HSQLDB 的测试框架。到目前为止一切正常，测试服务层轻而易举。然而，现在，在对表进行大规模导入（使用服务层、实体管理器）或例如在服务方法中将实体多次持久化到列表时，我们遇到了问题。

这是奇怪的部分：我们的测试似乎只有在使用 Maven 从命令行在足够快的工作站上运行时才会中断。当我通过 Eclipse IDE 运行测试时，一切都很好，但有时也会随机失败。我们怀疑这可能与测试运行的速度有关，听起来很奇怪。例外很简单，因为它基本上告诉我们我们正在尝试添加一个具有现有 ID 的实体。我们多次检查了我们的测试数据和 hsqldb 数据库。没有我们正在尝试使用的带有 id 的预先存在的行。仍然 hsqldb 在某些时候抛出主键异常。从我们的日志中我们可以看到冲突的 ID 并不总是相同的，它可能是 300015 或 300008。

我们在这里束手无策。它可能与 HSQLDB 的事务或其他导致过时数据有关吗？

我们正在使用 HSQLDB 2.2.8、Eclipselink 2.3.0 和 OpenEJB 4.0.0-beta2。

我们尝试添加实体的关系映射如下：

@OneToMany(mappedBy = "invoice", cascade = CascadeType.PERSIST)
private List<InvoiceBalance> getInvoiceBalanceHistory() {
    if (invoiceBalanceHistory == null) {
        this.invoiceBalanceHistory = new ArrayList<InvoiceBalance>();
    }
    return invoiceBalanceHistory;
}

根本的例外是：

Caused by: java.sql.SQLIntegrityConstraintViolationException: integrity constraint violation: unique constraint or index violation; SYS_PK_10492 table: INVOICEBALANCE
at org.hsqldb.jdbc.Util.sqlException(Unknown Source)
at org.hsqldb.jdbc.Util.sqlException(Unknown Source)
at org.hsqldb.jdbc.JDBCPreparedStatement.fetchResult(Unknown Source)
at org.hsqldb.jdbc.JDBCPreparedStatement.executeUpdate(Unknown Source)
at org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:105)
at org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:105)
at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.executeDirectNoSelect(DatabaseAccessor.java:831)
... 82 more
Caused by: org.hsqldb.HsqlException: integrity constraint violation: unique constraint or   index violation; SYS_PK_10492 table: INVOICEBALANCE
at org.hsqldb.error.Error.error(Unknown Source)
at org.hsqldb.Constraint.getException(Unknown Source)
at org.hsqldb.index.IndexAVLMemory.insert(Unknown Source)
at org.hsqldb.persist.RowStoreAVL.indexRow(Unknown Source)
at org.hsqldb.TransactionManager2PL.addInsertAction(Unknown Source)
at org.hsqldb.Session.addInsertAction(Unknown Source)
at org.hsqldb.Table.insertSingleRow(Unknown Source)
at org.hsqldb.StatementDML.insertSingleRow(Unknown Source)
at org.hsqldb.StatementInsert.getResult(Unknown Source)
at org.hsqldb.StatementDMQL.execute(Unknown Source)
at org.hsqldb.Session.executeCompiledStatement(Unknown Source)
at org.hsqldb.Session.execute(Unknown Source)

编辑：

我将主键生成策略从 GenerationType.AUTO（默认情况下似乎使用 TABLE 策略）更改为 IDENTITY。在此之后，我们的质量持续存在似乎不会失败。我仍然不知道为什么 HSQLDB 与 TABLE 策略“不同步”。我不想仅仅因为我们的测试框架有问题就改变我们的 jpa 实体 :)

4

3 回答 3

0

很可能，您在将大量行导入MEMORY表时内存不足。

您应该增加内存分配或将此特定表定义为CACHED表。

更新：CACHED表可以在持久性数据库中使用，而不是在全内存数据库中：

CREATE CACHED TABLE mytable ...

或对于现有表：

SET TABLE mytable TYPE CACHED

更新：

如果这不是由 OOM 引起的，正如更改生成策略所证实的那样，那么生成策略似乎可能不会在某些时候增加生成的主键值。身份策略依赖于数据库来创建生成的值，效果很好。

于 2012-04-16T11:02:07.933 回答
0

您的 allocationSize 可能会在相对快速的平台上或偶尔定义瓶颈。即，当默认为 GenerationType.AUTO 时，表 EclipseLink 的默认设置将缓存 ID 到分配的值。然后它将查找生成器以确认其最后分配的值。如果在下一组 ID 被缓存之前在 allocationSize 的边缘进行查找，那么您可能会遇到竞争条件，其中 eclipse 链接在更新缓存之前两次分配缓存中的最后一个 id 并尝试将两者用于插入并且两个插入都失败并回滚。如果可以，您应该检查是否在您的分配缓存应该增加时发生这种情况，但也许这种检查可能会改变行为

于 2014-03-13T19:04:10.873 回答
0

对于integrity constraint violation: unique constraint or index violation 如果您是调试器狂，您可以在调试模式下重建 hsqldb 并在已org.hsqldb.index.IndexAVLMemory#insert为变量compare分配断点条件的行设置断点compare == 0。

错误的行（例如重复的行）将是作为参数传递的行。

于 2016-06-10T14:51:58.873 回答