JDO TCK Conference Call Friday October 9, 11:30 am Pacific Daylight Time (PDT)

[Michael Bouschen]

Hi,

We will have our regular meeting Friday, October 9 at 11:30 am Pacific Daylight 
Time (PDT) to discuss JDO TCK issues and status. 

Dial-in numbers are:
US Toll free: 866 682-4770
Germany Frankfurt +49 69 222 216 106
Germany Munich: +49 89 1430 2323
(Other countries by request)

To place the call:
1. Call the toll free number.
2. Enter the conference number 939-3689#
3. Enter the security code #

We use the conference call for audio and use Google Hangouts for screen sharing 
and video.
The Google Hangouts URL for the meeting: http://goo.gl/sCKJaS

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. New comments on JIRA JDO-747 "Behavior of delete() with multiple concurrent 
Transactions" https://issues.apache.org/jira/browse/JDO-747
3. Other issues

Action Items from weeks past:
[May 15 2015] AI Craig Spec change for roll back an active transaction when 
closing a persistence manager (JDO-735)  
[Apr 17 2015] AI Craig: Oracle spec page on JDO need to be updated once the JCP 
Maintenance Release for JDO 3.1 is published
[Oct 17 2014] AI Matthew any updates for "Modify specification to address NoSQL 
datastores": https://issues.apache.org/jira/browse/JDO-651?
[Feb 28 2014] AI Everyone: take a look at 
https://issues.apache.org/jira/browse/JDO-712
[Feb 28 2014] AI Everyone: take a look at 
https://issues.apache.org/jira/browse/JDO-625
[Dec 13 2013] AI Craig file a JIRA for java.sql.Blob and java.sql.Clob as 
persistent field types
[Aug 24 2012] AI Craig update the JIRAs JDO-689 JDO-690 and JDO-692 about 
JDOHelper methods. In process.

Regards Michael 

-- 
*Michael Bouschen*
*Prokurist*

akquinet tech@spree GmbH
Bülowstr. 66, D-10783 Berlin

Fon:   +49 30 235 520-33
Fax:   +49 30 217 520-12
Email: michael.bousc...@akquinet.de
Web:   www.akquinet.de 

akquinet tech@spree GmbH, Berlin
Geschäftsführung: Martin Weber, Dr. Torsten Fink
Amtsgericht Berlin-Charlottenburg HRB 86780 B
USt.-Id. Nr.: DE 225 964 680

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

[JIRA]

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

Tilmann Zäschke commented on JDO-747:
-

If this is not urgent, I would volunteer to contribute, for example write a 
patch for the TCK. I'm quite busy at the moment, but I could do it in November, 
if that's okay.

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