JPA executeUpdate始终返回1

时间:2015-06-19 09:54:44

标签: java jpa

我遇到一个问题,即使没有要更新的记录,executeUpdate命令总是返回值1。

首先,我检索几条记录,进行一些计算,然后更新一些检索记录的状态。

JPA更新代码:

private int executeUpdateStatusToSuccess(Long id, Query updateQuery) {
    updateQuery.setParameter(1, getSysdateFromDB());
    updateQuery.setParameter(2, id);
    int cnt = updateQuery.executeUpdate();
    return cnt; // always return 1
}

更新查询:

UPDATE PRODUCT_PARAM SET STATUS = 2, DATA_TIMESTAMP=? WHERE ID = ? AND STATUS=-1

请注意, STATUS 列实际上从未被评估过< 0.我故意在这里添加这个条件只是为了表明即使它不应该更新任何记录,executeUpdate()仍然返回值1.

作为补充说明,数据检索和更新之间没有任何更新过程。这一切都是在我当地的环境中完成的。

如果我在这里遗漏任何东西,有什么建议吗?或者,如果有一些配置参数需要checK?

编辑: 对于JPA,我正在使用EclipseLink。 对于数据库,我使用带有驱动程序ojdbc5.jar的Oracle 10g。

1 个答案:

答案 0 :(得分:0)

最后,我必须查看EclipseLink JPA源代码。所以系统实际执行这一行

return Integer.valueOf(1);

来自以下basicExecuteCallDatabaseAccessor方法中的代码:

if (isInBatchWritingMode(session)) {
    // if there is nothing returned and we are not using optimistic locking then batch
    //if it is a StoredProcedure with in/out or out parameters then do not batch
    //logic may be weird but we must not batch if we are not using JDBC batchwriting and we have parameters
    // we may want to refactor this some day
    if (dbCall.isNothingReturned() && (!dbCall.hasOptimisticLock() || getPlatform().canBatchWriteWithOptimisticLocking(dbCall) ) 
        && (!dbCall.shouldBuildOutputRow()) && (getPlatform().usesJDBCBatchWriting() || (!dbCall.hasParameters())) && (!dbCall.isLOBLocatorNeeded())) {
        // this will handle executing batched statements, or switching mechanisms if required
        getActiveBatchWritingMechanism().appendCall(session, dbCall);
        //bug 4241441: passing 1 back to avoid optimistic lock exceptions since there   
        // is no way to know if it succeeded on the DB at this point.
        return Integer.valueOf(1);
    } else {
        getActiveBatchWritingMechanism().executeBatchedStatements(session);
    }
}

一个简单的黑客就是不使用批次。我尝试在persistence.xml中将其关闭,更新返回预期值,即0。

<property name="eclipselink.jdbc.batch-writing" value="none" />

我期待更好的解决方案,但在我的情况下,这个问题现在可以做到。