[
https://issues.apache.org/jira/browse/JDO-747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14875949#comment-14875949
]
Craig L Russell commented on JDO-747:
-------------------------------------
I'm sympathetic to the idea that you should be able to recover a transaction
where there is a delete conflict that the current specification does not allow.
One effect of refresh on an object is that the object is removed from the list
of objects to be flushed to the database.
The change needed is in the life cycle for refresh of a deleted object which
could depend on the state of the object in the database. For example, refresh
where the object was not there would result in a state change to Hollow? And
refresh where the object was there would result in a state change to
Persistent-clean? And we can also open the discussion whether an exception
needs to be thrown on refresh.
Maybe it would help clarify our options for you to write a test case which has
a delete conflict and what can be done to recover. Begin a transaction, change
an object, insert an object, delete an object; in a second transaction do the
same and commit; in the first transaction flush to sync with the datastore,
catch the exception and now...
recover the failed objects so the transaction can succeed.
> 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)
