[jira] [Updated] (JDO-747) Behavior of delete() with multiple concurrent Transactions
[
https://issues.apache.org/jira/browse/JDO-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tilmann Zäschke updated JDO-747:
Attachment: (was: Ch12-PersistenceManager-No-747.odt)
> 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
>Assignee: Tilmann Zäschke
>Priority: Minor
> Labels: concurrency, delete, refresh
> Attachments: Ch05-LifeCycle-With-747.odt,
> Ch12-PersistenceManager-With-747-Changes-Marked.odt,
> Ch12-PersistenceManager-With-747.odt,
> JDO-StateTransition-logs-2015-12-04.zip, OptimisticCheckConsistency.java,
> OptimisticFailurePatch_JDO747.txt, StateTransitionPatch_JDO747_v6.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
(v7.6.3#76005)
[jira] [Updated] (JDO-747) Behavior of delete() with multiple concurrent Transactions
[
https://issues.apache.org/jira/browse/JDO-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tilmann Zäschke updated JDO-747:
Attachment: Ch12-PersistenceManager-With-747-Changes-Marked.odt
> 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
>Assignee: Tilmann Zäschke
>Priority: Minor
> Labels: concurrency, delete, refresh
> Attachments: Ch05-LifeCycle-With-747.odt,
> Ch12-PersistenceManager-With-747-Changes-Marked.odt,
> Ch12-PersistenceManager-With-747.odt,
> JDO-StateTransition-logs-2015-12-04.zip, OptimisticCheckConsistency.java,
> OptimisticFailurePatch_JDO747.txt, StateTransitionPatch_JDO747_v6.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
(v7.6.3#76005)
[jira] [Updated] (JDO-747) Behavior of delete() with multiple concurrent Transactions
[
https://issues.apache.org/jira/browse/JDO-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Bouschen updated JDO-747:
-
Fix Version/s: (was: JDO 3.2)
> 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
>Assignee: Tilmann Zäschke
>Priority: Minor
> Labels: concurrency, delete, refresh
> Attachments: Ch05-LifeCycle-With-747.odt,
> Ch12-PersistenceManager-No-747.odt, Ch12-PersistenceManager-With-747.odt,
> JDO-StateTransition-logs-2015-12-04.zip, OptimisticCheckConsistency.java,
> OptimisticFailurePatch_JDO747.txt, StateTransitionPatch_JDO747_v6.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
(v7.6.3#76005)
[jira] [Updated] (JDO-747) Behavior of delete() with multiple concurrent Transactions
[
https://issues.apache.org/jira/browse/JDO-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tilmann Zäschke updated JDO-747:
Attachment: (was: Ch12-PersistenceManager.odt)
> 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
>Assignee: Tilmann Zäschke
>Priority: Minor
> Labels: concurrency, delete, refresh
> Fix For: JDO 3.2
>
> Attachments: Ch05-LifeCycle-With-747.odt,
> Ch12-PersistenceManager-No-747.odt, Ch12-PersistenceManager-With-747.odt,
> JDO-StateTransition-logs-2015-12-04.zip, OptimisticCheckConsistency.java,
> OptimisticFailurePatch_JDO747.txt, StateTransitionPatch_JDO747_v6.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
(v7.6.3#76005)
[jira] [Updated] (JDO-747) Behavior of delete() with multiple concurrent Transactions
[
https://issues.apache.org/jira/browse/JDO-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tilmann Zäschke updated JDO-747:
Attachment: (was: Ch05-LifeCycle.odt)
> 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
>Assignee: Tilmann Zäschke
>Priority: Minor
> Labels: concurrency, delete, refresh
> Fix For: JDO 3.2
>
> Attachments: Ch05-LifeCycle-With-747.odt,
> Ch12-PersistenceManager-No-747.odt, Ch12-PersistenceManager-With-747.odt,
> JDO-StateTransition-logs-2015-12-04.zip, OptimisticCheckConsistency.java,
> OptimisticFailurePatch_JDO747.txt, StateTransitionPatch_JDO747_v6.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
(v7.6.3#76005)
[jira] [Updated] (JDO-747) Behavior of delete() with multiple concurrent Transactions
[
https://issues.apache.org/jira/browse/JDO-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tilmann Zäschke updated JDO-747:
Attachment: Ch12-PersistenceManager-With-747.odt
Ch05-LifeCycle-With-747.odt
> 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
>Assignee: Tilmann Zäschke
>Priority: Minor
> Labels: concurrency, delete, refresh
> Fix For: JDO 3.2
>
> Attachments: Ch05-LifeCycle-With-747.odt,
> Ch12-PersistenceManager-No-747.odt, Ch12-PersistenceManager-With-747.odt,
> JDO-StateTransition-logs-2015-12-04.zip, OptimisticCheckConsistency.java,
> OptimisticFailurePatch_JDO747.txt, StateTransitionPatch_JDO747_v6.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
(v7.6.3#76005)
[jira] [Updated] (JDO-747) Behavior of delete() with multiple concurrent Transactions
[
https://issues.apache.org/jira/browse/JDO-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tilmann Zäschke updated JDO-747:
Attachment: Ch12-PersistenceManager.odt
Ch05-LifeCycle.odt
> 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
>Assignee: Tilmann Zäschke
>Priority: Minor
> Labels: concurrency, delete, refresh
> Fix For: JDO 3.2
>
> Attachments: Ch05-LifeCycle.odt, Ch12-PersistenceManager-No-747.odt,
> Ch12-PersistenceManager.odt, JDO-StateTransition-logs-2015-12-04.zip,
> OptimisticCheckConsistency.java, OptimisticFailurePatch_JDO747.txt,
> StateTransitionPatch_JDO747_v6.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
(v7.6.3#76005)
[jira] [Updated] (JDO-747) Behavior of delete() with multiple concurrent Transactions
[
https://issues.apache.org/jira/browse/JDO-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tilmann Zäschke updated JDO-747:
Attachment: Ch12-PersistenceManager-No-747.odt
> 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
>Assignee: Tilmann Zäschke
>Priority: Minor
> Labels: concurrency, delete, refresh
> Fix For: JDO 3.2
>
> Attachments: Ch12-PersistenceManager-No-747.odt,
> JDO-StateTransition-logs-2015-12-04.zip, OptimisticCheckConsistency.java,
> OptimisticFailurePatch_JDO747.txt, StateTransitionPatch_JDO747_v6.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
(v7.6.3#76005)
[jira] [Updated] (JDO-747) Behavior of delete() with multiple concurrent Transactions
[
https://issues.apache.org/jira/browse/JDO-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Craig L Russell updated JDO-747:
Labels: concurrency delete refresh (was: concurrency delete documentation
refresh() specification)
> 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, refresh
> Fix For: JDO 3.2
>
> Attachments: JDO-StateTransition-logs-2015-12-04.zip,
> OptimisticCheckConsistency.java, OptimisticFailurePatch_JDO747.txt,
> StateTransitionPatch_JDO747_v6.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
(v7.6.3#76005)
[jira] [Updated] (JDO-747) Behavior of delete() with multiple concurrent Transactions
[
https://issues.apache.org/jira/browse/JDO-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Bouschen updated JDO-747:
-
Fix Version/s: JDO 3.2
> 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-StateTransition-logs-2015-12-04.zip,
> OptimisticCheckConsistency.java, OptimisticFailurePatch_JDO747.txt,
> StateTransitionPatch_JDO747_v6.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.4.14#64029)
[jira] [Updated] (JDO-747) Behavior of delete() with multiple concurrent Transactions
[
https://issues.apache.org/jira/browse/JDO-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Bouschen updated JDO-747:
-
Fix Version/s: (was: JDO 3.2)
> 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
> Attachments: JDO-StateTransition-logs-2015-12-04.zip,
> OptimisticCheckConsistency.java, OptimisticFailurePatch_JDO747.txt,
> StateTransitionPatch_JDO747_v6.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.15#6346)
[jira] [Updated] (JDO-747) Behavior of delete() with multiple concurrent Transactions
[
https://issues.apache.org/jira/browse/JDO-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tilmann Zäschke updated JDO-747:
Attachment: StateTransitionPatch_JDO747_v5.txt
> 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-StateTransition-logs-2015-12-04.zip,
> OptimisticCheckConsistency.java, OptimisticFailurePatch_JDO747.txt,
> StateTransitionPatch_JDO747_v5.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)
[jira] [Updated] (JDO-747) Behavior of delete() with multiple concurrent Transactions
[
https://issues.apache.org/jira/browse/JDO-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tilmann Zäschke updated JDO-747:
Attachment: (was: StateTransitionPatch_JDO747_v4.txt)
> 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-StateTransition-logs-2015-12-04.zip,
> OptimisticCheckConsistency.java, OptimisticFailurePatch_JDO747.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)
[jira] [Updated] (JDO-747) Behavior of delete() with multiple concurrent Transactions
[
https://issues.apache.org/jira/browse/JDO-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Craig L Russell updated JDO-747:
Attachment: (was: JDO-747-Specification.rtf)
> 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-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)
[jira] [Updated] (JDO-747) Behavior of delete() with multiple concurrent Transactions
[
https://issues.apache.org/jira/browse/JDO-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tilmann Zäschke updated JDO-747:
Attachment: StateTransitionPatch_JDO747_v4.txt
Patch for StateTransition.java including test as specified in the specification
patch.
> 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)
[jira] [Updated] (JDO-747) Behavior of delete() with multiple concurrent Transactions
[
https://issues.apache.org/jira/browse/JDO-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tilmann Zäschke updated JDO-747:
Attachment: (was: StateTransitionPatch_JDO747_v3.txt)
> 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)
[jira] [Updated] (JDO-747) Behavior of delete() with multiple concurrent Transactions
[
https://issues.apache.org/jira/browse/JDO-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Craig L Russell updated JDO-747:
Attachment: JDO-747-Specification.rtf
> 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)
[jira] [Updated] (JDO-747) Behavior of delete() with multiple concurrent Transactions
[
https://issues.apache.org/jira/browse/JDO-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Craig L Russell updated JDO-747:
Attachment: (was: JDO-747-Specification.rtf)
> 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)
[jira] [Updated] (JDO-747) Behavior of delete() with multiple concurrent Transactions
[
https://issues.apache.org/jira/browse/JDO-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Craig L Russell updated JDO-747:
Attachment: (was: JDO-747-Specification.rtf)
> 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)
[jira] [Updated] (JDO-747) Behavior of delete() with multiple concurrent Transactions
[
https://issues.apache.org/jira/browse/JDO-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Craig L Russell updated JDO-747:
Attachment: JDO-747-Specification.rtf
> 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)
[jira] [Updated] (JDO-747) Behavior of delete() with multiple concurrent Transactions
[
https://issues.apache.org/jira/browse/JDO-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Craig L Russell updated JDO-747:
Attachment: JDO-747-Specification.rtf
Proposed specification updates have been uploaded.
> 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)
[jira] [Updated] (JDO-747) Behavior of delete() with multiple concurrent Transactions
[
https://issues.apache.org/jira/browse/JDO-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Craig L Russell updated JDO-747:
Attachment: JDO-747-Specification.rtf
> 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)
[jira] [Updated] (JDO-747) Behavior of delete() with multiple concurrent Transactions
[
https://issues.apache.org/jira/browse/JDO-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Craig L Russell updated JDO-747:
Attachment: (was: JDO-747-Specification.rtf)
> 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)
[jira] [Updated] (JDO-747) Behavior of delete() with multiple concurrent Transactions
[
https://issues.apache.org/jira/browse/JDO-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Craig L Russell updated JDO-747:
Attachment: JDO-747-Specification.rtf
> 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)
[jira] [Updated] (JDO-747) Behavior of delete() with multiple concurrent Transactions
[
https://issues.apache.org/jira/browse/JDO-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Craig L Russell updated JDO-747:
Attachment: (was: JDO-747-Specification.rtf)
> 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)
[jira] [Updated] (JDO-747) Behavior of delete() with multiple concurrent Transactions
[
https://issues.apache.org/jira/browse/JDO-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tilmann Zäschke updated JDO-747:
Attachment: JDO-StateTransition-logs-2015-12-04.zip
Sorry, not sure what happened, here are the logs again.
> 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-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)
[jira] [Updated] (JDO-747) Behavior of delete() with multiple concurrent Transactions
[
https://issues.apache.org/jira/browse/JDO-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tilmann Zäschke updated JDO-747:
Attachment: (was: JDO-StateTransition-logs-2015-11-29.zip)
> 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: 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)
[jira] [Updated] (JDO-747) Behavior of delete() with multiple concurrent Transactions
[
https://issues.apache.org/jira/browse/JDO-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tilmann Zäschke updated JDO-747:
Attachment: JDO-StateTransition-logs-2015-11-29.zip
JDO TCK error logs when running StateTransition test
> 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-StateTransition-logs-2015-11-29.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)
[jira] [Updated] (JDO-747) Behavior of delete() with multiple concurrent Transactions
[
https://issues.apache.org/jira/browse/JDO-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tilmann Zäschke updated JDO-747:
Attachment: (was: StateTransitionPatch_JDO747_v2.txt)
> 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: 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)
[jira] [Updated] (JDO-747) Behavior of delete() with multiple concurrent Transactions
[
https://issues.apache.org/jira/browse/JDO-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tilmann Zäschke updated JDO-747:
Attachment: StateTransitionPatch_JDO747_v3.txt
Improved StateTransitionPatch v3 that should avoid hanging tests.
> 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: 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)
[jira] [Updated] (JDO-747) Behavior of delete() with multiple concurrent Transactions
[
https://issues.apache.org/jira/browse/JDO-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tilmann Zäschke updated JDO-747:
Attachment: OptimisticCheckConsistency.java
This test checks detection consistency conflicts between optimistic
transactions and if the transaction can properly recover.
> 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: OptimisticCheckConsistency.java,
> OptimisticFailurePatch_JDO747.txt, StateTransitionPatch_JDO747_v2.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)
[jira] [Updated] (JDO-747) Behavior of delete() with multiple concurrent Transactions
[
https://issues.apache.org/jira/browse/JDO-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tilmann Zäschke updated JDO-747:
Attachment: StateTransitionPatch_JDO747_v2.txt
Improved patch (fix + cleanup)
> 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: StateTransitionPatch_JDO747_v2.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)
[jira] [Updated] (JDO-747) Behavior of delete() with multiple concurrent Transactions
[
https://issues.apache.org/jira/browse/JDO-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tilmann Zäschke updated JDO-747:
Attachment: (was: StateTransitionPatch_JDO747.txt)
> 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
>
>
> 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)
[jira] [Updated] (JDO-747) Behavior of delete() with multiple concurrent Transactions
[
https://issues.apache.org/jira/browse/JDO-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tilmann Zäschke updated JDO-747:
Attachment: OptimisticFailurePatch_JDO747.txt
Patch that check in OptimisticFailure for p-new
> 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: OptimisticFailurePatch_JDO747.txt,
> StateTransitionPatch_JDO747_v2.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)
[jira] [Updated] (JDO-747) Behavior of delete() with multiple concurrent Transactions
[
https://issues.apache.org/jira/browse/JDO-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tilmann Zäschke updated JDO-747:
Attachment: StateTransitions.java
StateTransitionPatch_JDO747.txt
I created a patch for the StateTransitions test. As expected, it currently
fails with a number of different errors, but I hope that the tests are correct.
I didn't modify the StateTransitionsReturnedObjects, as refresh() usually does
not return anything.
I couldn't find the optimistic tests with conflicts, except one for
non-transactional commit. Could you point them out to me?
> 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: StateTransitionPatch_JDO747.txt, StateTransitions.java
>
>
> 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)
[jira] [Updated] (JDO-747) Behavior of delete() with multiple concurrent Transactions
[
https://issues.apache.org/jira/browse/JDO-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Bouschen updated JDO-747:
-
Fix Version/s: JDO 3.2
> 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
>
>
> 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)
[jira] [Updated] (JDO-747) Behavior of delete() with multiple concurrent Transactions
[
https://issues.apache.org/jira/browse/JDO-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tilmann Zäschke updated JDO-747:
Description:
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?
was:
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?
> 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)
