[jira] [Commented] (JDO-747) Behavior of delete() with multiple concurrent Transactions

["Craig L Russell (JIRA)" <ji...@apache.org>]

    [ 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)