Optimistic transaction - Recovering after exception

Question

I'm looking for a usage pattern / hint for following problem:
We are using long-running optimistic transactions, where a large number of
JDO objects is modified during a transaction. Since multiple end users can
modify the same JDO objects, we can get OptimisticVerificationExceptions.
Following recovering strategies are trivial to implement:
- accept changes of the user who committed first by calling refresh() on the
conflicting JDO objects, discarding all changes made during the transaction
- step back to the state where the transaction began (with restoreValues set
to true), discarding all changes made during the transaction
However, we did not find a simple solution for recovering the following way:
- commit the changes of the user who received the exception, thus
overwriting the changes of the user who committed first
After retrieving a conflicting JDO object via getFailedObject(), it is
either in hollow or persistent-nontransactional state (depending on the
restoreValue property), so all changes that were made during the
transaction are lost. The only way I can think of is to copy/clone mapped
fields in preStore/preDelete instance callbacks and storing them in
transient fields within the JDO object. After receiving the exception, the
mapped fields could be set back to the values stored in the transient
fields. This approach appears somewhat clumsy, however. Are there better
ideas / proven usage patterns around?
Thanks,
Contus

Answer 1

Hi,
The JDO specification mandates that an OptimisticVerificationException is a
fatal exception and thus any transaction is implicitly rolled back and there
will no longer be an active optimistic transaction (hence why you are seeing
objects as hollow or PNT depending on RestoreValues).
The only thing that I can think of is to maybe use the detach() API to take
a copy of the objects you've changed prior to trying the commit. Then if
there is a failure you can begin a new tx and attach the detached
copies...not something I've tried but might work?
Cheers
- Keiron
"contus" <[email protected]> wrote in message
news:[email protected]...
I'm looking for a usage pattern / hint for following problem:
We are using long-running optimistic transactions, where a large number of
JDO objects is modified during a transaction. Since multiple end users can
modify the same JDO objects, we can get OptimisticVerificationExceptions.
Following recovering strategies are trivial to implement:
- accept changes of the user who committed first by calling refresh() onthe
conflicting JDO objects, discarding all changes made during thetransaction
- step back to the state where the transaction began (with restoreValuesset
to true), discarding all changes made during the transaction
However, we did not find a simple solution for recovering the followingway:
- commit the changes of the user who received the exception, thus
overwriting the changes of the user who committed first
After retrieving a conflicting JDO object via getFailedObject(), it is
either in hollow or persistent-nontransactional state (depending on the
restoreValue property), so all changes that were made during the
transaction are lost. The only way I can think of is to copy/clone mapped
fields in preStore/preDelete instance callbacks and storing them in
transient fields within the JDO object. After receiving the exception, the
mapped fields could be set back to the values stored in the transient
fields. This approach appears somewhat clumsy, however. Are there better
ideas / proven usage patterns around?
Thanks,
Contus