[
https://issues.apache.org/jira/browse/JDO-747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103867#comment-15103867
]
Tilmann Zäschke commented on JDO-747:
-------------------------------------
Craig:
4) My concern was that if an object is modified remotely (non-optimistic), a
W-LOCK would be put on it. Then a local PM couldn't modify it because it can't
put an R-LOCK on it anymore. However you now said that locks in the DB will
only occur upon flush() or commit(). But isn't that what optimistic
transactions usually do, i.e. being by optimistic by delaying locks until
commit()?
Sorry, I'm still a bit unsure about JDO's concept of transactions. Please let
me know if this is not the right place to discuss this or where I can find a
definition.
Questions:
a) If locking occurs only during commit() (and flush), what is the difference
between normal and optimistic transaction? (except that optimistic objects
transition to non-transactional)
b) What is the rationale of transitioning to non-transactional on read? I used
optimistic transactions quite a bit with a commercial ODBMS, but I never had
the desire to make objects non-transactional...
> 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
> Fix For: JDO 3.2
>
> Attachments: JDO-747-Specification.rtf,
> JDO-StateTransition-logs-2015-12-04.zip, OptimisticCheckConsistency.java,
> OptimisticFailurePatch_JDO747.txt, StateTransitionPatch_JDO747_v4.txt
>
>
> 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)
