[jira] [Commented] (JDO-747) Behavior of delete() with multiple concurrent Transactions
[
https://issues.apache.org/jira/browse/JDO-747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222121#comment-15222121
]
Andy Jefferson commented on JDO-747:
Perhaps the requester of this "feature" can work on implementation in the RI?
I'm available to offer help in where to find things in the source code etc but
have not been following what this is all about, and makes sense for other
people to develop the RI not just 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: 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)
Minutes: JDO TCK Conference Call Friday April 1, 9 AM Pacific Daylight Time (PDT)
Attendees: Tilmann Zäschke, Michael Bouschen, Craig Russell Agenda: 1. JDO 3.1: Need to go through change lists in JIRA for 3.1 RC1 and 3.1 to prepare JCP Change Log 2. JDO social media properties (see email from Matthew) 3. JDO-751 "Support for Java8 Optional" https://issues.apache.org/jira/browse/JDO-751 Tests for Optional are in progress. Domain class has Optional attributes, not integrated with the rest of the model classes. Is Optionalallowed? It doesn’t make sense since Optional should never have a null value. Null is represented by Optional.empty(). Reductio ad absurdum argument: Why not Optional
[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] [Commented] (JDO-747) Behavior of delete() with multiple concurrent Transactions
[
https://issues.apache.org/jira/browse/JDO-747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15221932#comment-15221932
]
Craig L Russell commented on JDO-747:
-
The specification draft has been updated. Open the specification chapters 5 and
12 to review the changes.
jdo/trunk/specification/OOO/Ch05-LifeCycle.odt
jdo/trunk/specification/OOO/Ch12-PersistenceManager.odt
Edit> Changes> Accept or Reject will show the recent changes
> 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] [Commented] (JDO-751) Support for Java8 Optional
[ https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15221921#comment-15221921 ] Craig L Russell commented on JDO-751: - Regarding OptionalI think we should throw StupidUserException when trying to enhance a class with a property of type Optional If some user later has a real use case we can look at it then. > Support for Java8 Optional > -- > > Key: JDO-751 > URL: https://issues.apache.org/jira/browse/JDO-751 > Project: JDO > Issue Type: New Feature > Components: specification, tck >Reporter: Andy Jefferson > > java.util.Optional provides a feature that is available in other languages. > Since JDO 3.2 will be for Java8+ then it makes sense to add support for this > as a "supported persistable type" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
