[
https://issues.apache.org/jira/browse/JDO-747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15089629#comment-15089629
]
Craig L Russell commented on JDO-747:
-------------------------------------
Tilmann:
1. Yes, the specification will have a different order for these rows.
2. Yes, refresh will reflect the state of the object in the datastore so its
local state will change. The objective is that after refresh, the object
refreshed is no longer in conflict, so a commit will succeed if no other
changes are made either in the datastore or the local transaction.
3. The intent is that the object (now) exists in the datastore and the local
transaction needs to reflect this.
4. In datastore transactions, it is possible to get an object, modify or delete
it, and then flush, refresh, or commit it. You can always modify or delete an
object in a transaction, even if the object has been locked in a parallel
transaction. The conflict will detected on flush or commit.
You are right that optimistic transactions check consistency at commit (or
flush) and the consistency is based on values in the datastore (version
fields). With datastore transactions, there is no version checking.
Reading objects in datastore transactions should put read locks in the
datastore, preventing parallel transactions from flushing modifications or
deleting the object. But reading objects in optimistic transaction should not
leave any locks in the datastore.
So, in datastore transactions, write/write, write/delete, and delete/delete
conflicts can occur and these conflicts will be detected at flush or commit.
We're now changing the specification to allow transactions to recover from
these conflicts by using refresh. Similar conflicts can occur with optimistic
transactions.
The state transition from hollow to p-nontrans in optimistic occurs when
reading the datastore values including the version fields but leaving no locks
behind. This object will not be checked at flush or commit time because it is
not transactional. If you want the version fields to be checked, then you
should call makeTransactional.
> 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_v3.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)
