Issue Details (XML | Word | Printable)

Key: NUCCORE-518
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Peter Dettman
Reporter: Peter Dettman
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
DataNucleus Core

JDOPersistenceManagerFactory.close() behaviour inconsistent with JDO javadoc/spec

Created: 29/Apr/10 06:42 AM   Updated: 04/Oct/12 05:02 PM   Resolved: 08/Jun/10 04:39 AM
Component/s: Persistence
Affects Version/s: 2.1.0.m2
Fix Version/s: 2.1.0.release

Forum Thread URL: http://www.jpox.org/servlet/forum/viewthread_thread,6096#32324


 Description  « Hide
JDO spec: "11.4 Close the PersistenceManagerFactory" (http://people.apache.org/~clr/jdo-2010-04-09.pdf)
Javadoc: http://db.apache.org/jdo/api23/apidocs/javax/...anagerFactory.html#close()

At least the following seem to need addressing:

1. It should be safe to call JDOPMF.close() multiple times (idempotent). Permission should be checked each time. Currently we call assertIsOpen() on method entry.

2. If any PMs have open transactions, none of them should be closed, and there should be no side-effects from the attempted JDOPMF.close() at all. The present handling does raise an exception, but some PMs may have closed.

3. JDOPMF.close() should freezeConfiguration(), or at least setIsNotConfigurable(). Presently there is a narrow possibility of closing before freezing, in which case set...() methods might not be disabled correctly.

4. Allowing get...() methods after close() seems to imply that they should also _work_. It's probably wrong then to clear the fetch groups during close, and there may be other state cleaned up prematurely.

5. I'm not sure what to make of the supportedOptions method. I'm inclined to treat it as a get...() method and allow it to be called after close. Javadoc would seem to allow that, but a strict reading of the spec seems to exclude that: "After close completes, disallow all methods except close, isClosed, and get methods except for getPersistenceManager."

As suggested, I have posted an issue with Apache JDO (https://issues.apache.org/jira/browse/JDO-653), and provided a patch for some of the TCK2 test cases.


Sort Order: Ascending order - Click to sort in descending order
Andy Jefferson added a comment - 29/Apr/10 10:58 AM
If the JDO TCK patch is applied to Apache JDO SVN trunk, then the fix to this also needs applying to core SVN branches/2.0 since DN 2.0.x is the RI for JDO2.3

Peter Dettman added a comment - 07/Jun/10 12:17 PM
These are all fixed in SVN. If and when there's some progress with the JDO issue mentioned above, I will apply to the 2.0 branch (unless, say, 2.1 has become the RI by then).

Andy Jefferson added a comment - 07/Jun/10 12:28 PM
Perhaps you meant 2.1

Andy Jefferson added a comment - 07/Jun/10 05:15 PM
Reopened til JDO TCK passes

Peter Dettman added a comment - 08/Jun/10 04:39 AM
Mea culpa. The TCK errors were due to adding "freezeConfiguration" to PMF.close() (many of the tests for close don't bother fully configuring the PMF properties, so e.g. there's no store manager).

I have changed PMF.close() to just call setIsNotConfigurable in place of freezeConfiguration, and have confirmed that the TCK now passes again.