Minutes: JDO TCK Conference Call Thursday March 15, 9:30 AM Pacific Time (PST)

[Craig Russell]

Attendees: Michael Bouschen, Tilmann Zäschke, Craig Russell

Next meeting: Thursday March 22 10:00 AM PDT

Agenda:

1. JDO-747 "Behavior of delete() with multiple concurrent Transactions" 
https://issues.apache.org/jira/browse/JDO-747

Need to back out changes in Chapter 5 and Chapter 12 for this JIRA, since the 
fix will not be available for 3.2. The RI will need to be updated and there is 
not time to do everything needed.

2. JDO-770 "Switch from svn to git" 
https://issues.apache.org/jira/browse/JDO-770

no news

3. JDO-766 "Support more JDBC-aware databases in JDO TCK" 
https://issues.apache.org/jira/browse/JDO-766

Michael is looking into the program that processes schema files. Perhaps keep 
the connect command but change it to a comment line, e.g. --connect ... As a 
restriction, the connect statement should be the first line in the file.

4. Issues with Fix Version JDO-3.2


Need a volunteer for JDO-712 Require using the PMF schema definition with 
sequence names

5. JDO 3.1: Need to go through change lists in JIRA for 3.1 RC1 and 3.1 to 
prepare JCP Change Log

6. Other issues

Action Items from weeks past:
[Jan 18 2018] AI Craig talk to some git/svn Apache experts to get some advice. 
Specifically, how to preserve the svn history, how to manage the web site.
[Oct 30 2015] AI Craig: File a maintenance review with JCP
[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.

Craig L Russell
Secretary, Apache Software Foundation
c...@apache.org http://db.apache.org/jdo

Minutes: JDO TCK Conference Call Thursday March 15, 9:30 AM Pacific Time (PST)

[Craig Russell]

Attendees: Michael Bouschen, Tilmann Zäschke, Craig Russell

Next meeting: Thursday March 22 10:00 AM PDT

Agenda:

1. JDO-747 "Behavior of delete() with multiple concurrent Transactions" 
https://issues.apache.org/jira/browse/JDO-747

Need to back out changes in Chapter 5 and Chapter 12 for this JIRA, since the 
fix will not be available for 3.2. The RI will need to be updated and there is 
not time to do everything needed.

2. JDO-770 "Switch from svn to git" 
https://issues.apache.org/jira/browse/JDO-770

no news

3. JDO-766 "Support more JDBC-aware databases in JDO TCK" 
https://issues.apache.org/jira/browse/JDO-766

Michael is looking into the program that processes schema files. Perhaps keep 
the connect command but change it to a comment line, e.g. --connect ... As a 
restriction, the connect statement should be the first line in the file.

4. Issues with Fix Version JDO-3.2


Need a volunteer for JDO-712 Require using the PMF schema definition with 
sequence names

5. JDO 3.1: Need to go through change lists in JIRA for 3.1 RC1 and 3.1 to 
prepare JCP Change Log

6. Other issues

Action Items from weeks past:
[Jan 18 2018] AI Craig talk to some git/svn Apache experts to get some advice. 
Specifically, how to preserve the svn history, how to manage the web site.
[Oct 30 2015] AI Craig: File a maintenance review with JCP
[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.

Craig L Russell
Secretary, Apache Software Foundation
c...@apache.org http://db.apache.org/jdo

[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=16400913#comment-16400913
 ] 

Tilmann Zäschke commented on JDO-747:
-

Preparation for 3.2:
 * Chapter 5 and 12 have been rolled back in SVN
 * The attached chapters contain the proposed spec changes for future use 
(Chapter 12 has two versions: once with change tracking and once without (for 
historical reasons))

> 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-712) Require using the PMF schema definition with sequence names

[Michael Bouschen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JDO-712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Bouschen updated JDO-712:
-
Priority: Minor  (was: Major)

> Require using the PMF schema definition with sequence names
> ---
>
> Key: JDO-712
> URL: https://issues.apache.org/jira/browse/JDO-712
> Project: JDO
>  Issue Type: Task
>  Components: specification, tck
>Affects Versions: JDO 3 (3.0)
>Reporter: Michael Bouschen
>Priority: Minor
> Fix For: JDO 3.2
>
>
> Chapter 18 XML Metadata of the spec defines that a schema declared at the 
> jdo, orm, package, class or interface level, specifies the schema to be used 
> as the default for tables contained therein. And if not specified the schema 
> defaults to the PMF schema property (see end of page 221 and beginning of 
> page 222 of the JDO 3.0 spec).
> The spec should define the same default for sequences. Then JDO 
> implementation would take the PMF schema definition to prefix the sequence 
> name the same way it currently does for all the table names. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JDO-744) XSD/DTD not published for JDO 3.1

[Craig L Russell (JIRA)]

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

Craig L Russell commented on JDO-744:
-

Need credentials from Oracle to upload the xsd files.

> XSD/DTD not published for JDO 3.1
> -
>
> Key: JDO-744
> URL: https://issues.apache.org/jira/browse/JDO-744
> Project: JDO
>  Issue Type: Bug
>  Components: api
>Affects Versions: JDO 3.1
>Reporter: Andy Jefferson
>Assignee: Craig L Russell
>Priority: Major
> Fix For: JDO 3.2
>
>
> Should be on 
> http://xmlns.jcp.org/xml/ns/jdo/jdo_3_1.xsd
> http://xmlns.jcp.org/dtd/jdo_3_1.dtd
> No idea how they are to get on that private server. Perhaps someone knows?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (JDO-744) XSD/DTD not published for JDO 3.1

[Michael Bouschen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JDO-744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Bouschen updated JDO-744:
-
Component/s: api

> XSD/DTD not published for JDO 3.1
> -
>
> Key: JDO-744
> URL: https://issues.apache.org/jira/browse/JDO-744
> Project: JDO
>  Issue Type: Bug
>  Components: api
>Affects Versions: JDO 3.1
>Reporter: Andy Jefferson
>Assignee: Craig L Russell
>Priority: Major
> Fix For: JDO 3.2
>
>
> Should be on 
> http://xmlns.jcp.org/xml/ns/jdo/jdo_3_1.xsd
> http://xmlns.jcp.org/dtd/jdo_3_1.dtd
> No idea how they are to get on that private server. Perhaps someone knows?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (JDO-744) XSD/DTD not published for JDO 3.1

[Craig L Russell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JDO-744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Craig L Russell reassigned JDO-744:
---

Assignee: Craig L Russell

> XSD/DTD not published for JDO 3.1
> -
>
> Key: JDO-744
> URL: https://issues.apache.org/jira/browse/JDO-744
> Project: JDO
>  Issue Type: Bug
>Affects Versions: JDO 3.1
>Reporter: Andy Jefferson
>Assignee: Craig L Russell
>Priority: Major
> Fix For: JDO 3.2
>
>
> Should be on 
> http://xmlns.jcp.org/xml/ns/jdo/jdo_3_1.xsd
> http://xmlns.jcp.org/dtd/jdo_3_1.dtd
> No idea how they are to get on that private server. Perhaps someone knows?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JDO-692) Constant string "javax.jdo.spi.PropertiesFileName" not defined in javax.jdo.Constants

[Craig L Russell (JIRA)]

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

Craig L Russell commented on JDO-692:
-

We need to check the RI to see if any of these constants are being used, and 
synchronize the API with the RI.

> Constant string "javax.jdo.spi.PropertiesFileName" not defined in 
> javax.jdo.Constants
> -
>
> Key: JDO-692
> URL: https://issues.apache.org/jira/browse/JDO-692
> Project: JDO
>  Issue Type: Bug
>  Components: api, specification
>Affects Versions: JDO 3 (3.0)
>Reporter: Matthew T. Adams
>Assignee: Craig L Russell
>Priority: Minor
> Fix For: JDO 3.2
>
>
> The JDO 3.0 specification page 103, bullet point 1 says 'the Map instance 
> passed to the static method will contain a property with a key of 
> "javax.jdo.spi.PropertiesFileName", and a value equal to the result of 
> calling getAbsolutePath() on the file parameter'.  There is no such constant 
> defined in javax.jdo.Constants.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (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: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

[JIRA]

 [ 
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

[Michael Bouschen (JIRA)]

 [ 
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

[JIRA]

 [ 
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

[JIRA]

 [ 
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

[JIRA]

 [ 
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

[JIRA]

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