DataNucleus JIRA is now in read-only mode. Raise any new issues in GitHub against the plugin that it applies to. DataNucleus JIRA will remain for the foreseeable future but will eventually be discontinued
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

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:,6096#32324

 Description  « Hide
JDO spec: "11.4 Close the PersistenceManagerFactory" (

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 (, and provided a patch for some of the TCK2 test cases.

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

Peter Dettman made changes - 07/Jun/10 12:17 PM
Field Original Value New Value
Status Open [ 1 ] Resolved [ 5 ]
Fix Version/s 2.2.0.release [ 10931 ]
Resolution Fixed [ 1 ]
Andy Jefferson added a comment - 07/Jun/10 12:28 PM
Perhaps you meant 2.1

Andy Jefferson made changes - 07/Jun/10 12:28 PM
Fix Version/s 2.1.0.release [ 10836 ]
Fix Version/s 2.2.0.release [ 10931 ]
Andy Jefferson added a comment - 07/Jun/10 05:15 PM
Reopened til JDO TCK passes

Andy Jefferson made changes - 07/Jun/10 05:15 PM
Resolution Fixed [ 1 ]
Status Resolved [ 5 ] Reopened [ 4 ]
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.

Peter Dettman made changes - 08/Jun/10 04:39 AM
Status Reopened [ 4 ] Resolved [ 5 ]
Resolution Fixed [ 1 ]
Andy Jefferson made changes - 11/Jun/10 01:38 PM
Status Resolved [ 5 ] Closed [ 6 ]
Andy Jefferson made changes - 04/Oct/12 05:02 PM
Component/s Persistence [ 10200 ]
Component/s JDO [ 10201 ]