[
https://issues.apache.org/jira/browse/JDO-747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14743242#comment-14743242
]
Tilmann Zäschke commented on JDO-747:
-------------------------------------
On the mailing list I got some clarifications from Craig Russell
Answer to point 1): ??Actually, it would be a conflict. If your application
thought it was deleting an object but the object wasn’t there, that would be an
error. The delete would fail and the transaction would fail.??
I believe that this behavior may be a bit overly cautious, because the main
goal of deleting the object was achieved. But I agree that Craig's explanation
makes sense in cases where we try to count how many object got deleted, and
thus provide better consistency guarantees.
Answer to point 2): ??Refresh would call the database and try to load the
object again and would fail.??.
This makes definitely sense.
3. _Question: "pm2 deletes the object and calls {{refresh()}}. According to the
spec, {{refresh()}} should not change the object's state."
_Answer:_ ??That is how I read the spec as well.??
_Question:_ "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?"
_Answer:_ ??Maybe when you file your JIRA, you can describe what you would like
to do to recover this situation, in as much detail as possible??
My problem with the third scenario (I locally delete an object that has been
deleted in the database):
The only way to recover from this scenario seems to be to call {{rollback()}}.
For all other changes that another {{PersistenceManager}} can make to a
database, I can simply call {{refresh()}} to recover, but not for deleted
objects. What I meant is: I can't recover the current transaction, I have to
start a new one.
I'm not sure why this is the case. Wouldn't it make sense if {{refresh()}}
would mark the loaded object as deleted so that I can recover a running
transaction without having to restart it?
> 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)
