Java Data Objects

Modifying Instances

A persistent-nontransactional instance transitions to persistent-dirty if your application modifies a managed field while an optimistic transaction is in progress. The JDO implementation saves the values of the fields of the instance in memory for use during rollback and for verification during commit. The saved values of fields in the instance in memory are unchanged before the update is applied. To minimize the possibility of a verification failure at commit, you can call refresh( ) or refreshAll( ) with the instance as a parameter before making the first change to the instance in the transaction.

If you make changes to instances outside a transaction using the NontransactionalWrite feature, the changes are assumed to reflect the current state of the field values in the datastore. Therefore, with a policy that uses field-value verification, if you make changes to the same instances in a subsequent optimistic transaction, the changes made outside the transaction will be the values used for comparison. With a policy that depends on a special field in the object, the only way to avoid a verification failure is to refresh the instance prior to making the changes.