Skip to content

Conversation

@quaff
Copy link
Contributor

@quaff quaff commented Mar 27, 2025

The version from query result is nondeterministic, it's not definitely same to the moment update executed because it may be altered right after that moment, it's not definitely same to the latest version in database because it may be altered right after the query executed. Given that, the current version is not so useful for troubleshooting in practice.

The version from query result is nondeterministic, it's not definitely same to the moment update executed because it may be altered right after that moment, it's not definitely same to the latest version in database because it may be altered right after the query executed. Given that, the current version is not so useful for troubleshooting in practice.

Signed-off-by: Yanming Zhou <[email protected]>
@fmbenhassine fmbenhassine added this to the 6.0.0-RC1 milestone Sep 11, 2025
@fmbenhassine
Copy link
Contributor

Thank you for the PR. I think we still need to check for the version in the database before throwing the OLFE. In fact, that's what this kind of guards are for, not necessarily for troubleshooting.

Similarly to what was added in 549c1ef, I think an additional check is missing as well:

public void deleteJobInstance(JobInstance jobInstance) {
    int count = getJdbcTemplate().update(getQuery(DELETE_JOB_INSTANCE), jobInstance.getId(),
            jobInstance.getVersion());

    if (count == 0) {
        // At this point, what if another thread is/was trying to update the instance (ie has changed the version)
        // in the database while we are trying to delete it? So I think we need to query for the version here
        // before throwing an exception.
        throw new OptimisticLockingFailureException("Attempt to delete job instance id="
             + jobInstance.getId() + " with wrong version (" + jobInstance.getVersion() + ")");
    }
}

I understand that this is unlikely and I might be missing something, but I think this is what all this optimistic locking strategy is there for. Do you agree?

@fmbenhassine fmbenhassine removed this from the 6.0.0-RC1 milestone Oct 21, 2025
@fmbenhassine fmbenhassine added the status: waiting-for-reporter Issues for which we are waiting for feedback from the reporter label Oct 21, 2025
@quaff
Copy link
Contributor Author

quaff commented Oct 22, 2025

This commit doesn't break optimistic locking, just removing useless current version from OptimisticLockingFailureException message to eliminate one db query.

@fmbenhassine fmbenhassine added status: feedback-provided Issues for which the feedback requested from the reporter was provided and removed status: waiting-for-reporter Issues for which we are waiting for feedback from the reporter labels Oct 22, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

status: feedback-provided Issues for which the feedback requested from the reporter was provided

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants