[
https://issues.apache.org/jira/browse/JDO-747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14940620#comment-14940620
]
Craig L Russell commented on JDO-747:
-------------------------------------
When checkConsistency is called, the objects that would not be successfully
committed are identified in the JDOOptimisticVerificationException. These
objects are in states where the current datastore state would conflict at
commit time.
The specification doesn't say what the state of objects after checkConsistency,
so assume that the states are unchanged.
p-new objects where there is already an object in the datastore: refresh and
modify the object to be consistent
p-dirty objects that conflict with changes in the datastore: refresh and
synchronize with the rest of cache
p-deleted objects that have already been deleted: nothing except to refresh and
synchronize with the rest of cache
So, we need a new way to tell for each failed object what needs to be done to
continue the transaction. Here are some changes we could make to the state
transition rules, for objects that fail checkConsistency.
p-dirty objects after optimistic refresh are either:
p-nontrans with fresh values from the datastore; update this object with new
values -> p-dirty
isPersistent = true
transient if the object does not exist in the datastore; makePersistent if
you want the object to exist
isPersistent = false
p-new objects after optimistic refresh are either:
p-new if the object does not already exist; nothing is needed to make the
object persistent
isNew = true
p-nontrans with fresh values from the datastore; update with values -> p-dirty
isNew = false
p-deleted objects after optimistic refresh are either:
p-deleted if the object exists in the datastore; nothing else is needed to
delete the object
isDeleted = true
p-nontrans if the object has already been deleted; nothing else is needed to
delete the object
isDeleted = false
With the above rules, refresh or refreshAll would not throw
ObjectNotFoundException because the application can tell what the state is by
interrogation.
> Behavior of delete() with multiple concurrent Transactions
> ----------------------------------------------------------
>
> Key: JDO-747
> URL: https://issues.apache.org/jira/browse/JDO-747
> Project: JDO
> Issue Type: Improvement
> Components: specification
> Affects Versions: JDO 3.1
> Reporter: Tilmann Zäschke
> Priority: Minor
> Labels: concurrency, delete, documentation, refresh(),
> specification
>
> In the Spec I could not find any statement regarding on how a transaction
> should behave if an object is deleted in a different concurrent transaction.
> Related Sections are Section 5.8 (how different methods should behave for
> different object states) and Section 12.6.1 (the behavior of refresh() and
> related methods).
> For example I wonder about the following situations. Suppose I have two
> optimistic sessions, pm1 and pm2, both access the same object. pm1 deletes
> the object and commits. Then what happens in pm2 if:
> 1. pm2 deletes the object and tries to commit, should that work? It's
> wouldn't be a real conflict if both delete it.
> 2. pm2 modifies the object (make dirty) and calls {{refresh()}}. Should I
> get an {{ObjectNotFound}} exception?
> 3. pm2 deletes the object and calls {{refresh()}}. According to the spec,
> {{refresh()}} should not change the object's state. But should it
> still fail with {{ObjectNotFound}}? If refresh should fail, how can I
> ever recover from such a situation, because I can't undelete the
> object?
> Is there a common understanding how this should work?
> IF there an external definition JDO relies on, then I think a reference to an
> external document might useful.
> If not, should the Spec define concurrent behavior?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
