[ https://issues.apache.org/jira/browse/JDO-747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15055180#comment-15055180 ]
Tilmann Zäschke commented on JDO-747: ------------------------------------- If have some questions on the proposed spec updates: # On the second page, the rows are in reverse order. I suppose they should have the same order? # p-new-del and p-del: In the discussion above it was said that they would remain 'unchanged' when the remote object is updated. Now they transition to transition to p-clean/p-nontrans. I agree with this, I assume this was decided in one of the teleconferences? # In the left table column, it says "inserted in parallel transaction". Maybe this should be changed to "updated", because I think "inserted" sounds like it is a newly added object. # I'm not sure that all of the states are possible, especially for the DS transactions. For example, the states p-dirty and p-deleted cannot occur in a transaction PM1 when the object is modified in a parallel PM2. If the 'remote' transaction PM2 changes/deletes the object, changing the object locally in PM1 to 'dirty' may not work because it may realise that the object has been modified/removed by the remote transaction PM2 and throw an exception. I realised that I'm not sure what an 'optimistic' transaction is. I assumed it simply means that consistency is only checked during commit, whereas a non-optimistic transaction checks consistency as early as possible (pessimistic locking). But that doesn't explain why the state transitions in optimistic transactions are different then in pessimistic transactions, i.e. why hollow -> p-nontransactional when accessing a field (Section 5.8). Could someone point me to some more information about this? The tests don't fully reflect the proposed spec updates, so I will update them. > 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)