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

2016-04-04 Thread JIRA

[ 
https://issues.apache.org/jira/browse/JDO-747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15223983#comment-15223983
 ] 

Tilmann Zäschke commented on JDO-747:
-

I think this is a bit more of 'change' of behaviour, not really a new feature. 
The idea is that when concurrent transactions fail because of a delete() in one 
of them, then there should be a way to recover the other transaction, for 
example by calling {{refresh()}}. So the change in behaviour is that 
{{refresh()}} should change the deleted object's state to something meaningful, 
instead of failing.

As it happens, the outcome of this JIRA has changed a bit, so I have to catch 
up myself with the latest development (the expected state of the refreshed 
objects).

I'm currently working on the tests. After that I have the tests for SPR 751 
(Java Optional) in my pipeline, so I could look into adapting the RI after 
that. But it'll take a bit before I have time, and I wouldn't mind if someone 
else could adapt the RI. 

> 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-751) Support for Java8 Optional

2016-04-04 Thread JIRA

[ 
https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15224000#comment-15224000
 ] 

Tilmann Zäschke commented on JDO-751:
-

I just realise that throwing an exception during enhancement probably won't be 
possible, because after type erasure, the field will simply be of type 
{{Optional}}. Chained {{Optional>}} can only be detected during 
serilization.

Should we throw the Exception during serialization?

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