Re: Optimistic Locking issue

[Lukas Eder]

Hello Ryan,

> I guess there is no way to automatically handle this as JOOQ can't be sure
> when the underlying transaction is actually committed? I'm not sure how this
> situation is normally handled with optimistic locking and transactions.

jOOQ would have to go very far in order to implement transaction state
listeners that would be triggered on a rollback. I'm thinking about
distributed transactions, where the transactional state is separated
from the JDBC connection and maintained in a
javax.transaction.UserTransaction...

So no, jOOQ can't and probably shouldn't handle this automatically. An
option for you would be this jOOQ 2.7 / 3.0 logic:

public <R extends UpdatableRecord<R>> void myStore(R record) {

    // Create a copy with the same changed flag values
    int size = record.getFields().size();
    boolean[] flags = new boolean[size];
    for (int i = 0; i < size; i++) {
        flags[i] = record.changed(i);
    }

    try {
        record.store();
    }
    catch (DataAccessException e) {
        for (int i = 0; i < size; i++) {
            record.changed(flags[i]);
        }

        doRollback();
    }
}