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

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

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.

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