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?

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

JdbcJobExecutionDao.CURRENT_VERSION_JOB_EXECUTION should be removed also if #5365 merged.