[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=14940620#comment-14940620 ] 

Craig L Russell commented on JDO-747:
-------------------------------------

When checkConsistency is called, the objects that would not be successfully committed are identified in the JDOOptimisticVerificationException. These objects are in states where the current datastore state would conflict at commit time. 

The specification doesn't say what the state of objects after checkConsistency, so assume that the states are unchanged.

p-new objects where there is already an object in the datastore: refresh and modify the object to be consistent
p-dirty objects that conflict with changes in the datastore: refresh and synchronize with the rest of cache
p-deleted objects that have already been deleted: nothing except to refresh and synchronize with the rest of cache

So, we need a new way to tell for each failed object what needs to be done to continue the transaction. Here are some changes we could make to the state transition rules, for objects that fail checkConsistency.

p-dirty objects after optimistic refresh are either:
  p-nontrans with fresh values from the datastore; update this object with new values -> p-dirty
    isPersistent = true
  transient if the object does not exist in the datastore; makePersistent if you want the object to exist
    isPersistent = false
p-new objects after optimistic refresh are either:
  p-new if the object does not already exist; nothing is needed to make the object persistent 
    isNew = true
  p-nontrans with fresh values from the datastore; update with values -> p-dirty
    isNew = false
p-deleted objects after optimistic refresh are either:
  p-deleted if the object exists in the datastore; nothing else is needed to delete the object
    isDeleted = true
  p-nontrans if the object has already been deleted; nothing else is needed to delete the object
    isDeleted = false

With the above rules, refresh or refreshAll would not throw ObjectNotFoundException because the application can tell what the state is by interrogation.

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