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.
Get Java Data Objects now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.