It is not clear when the real PersistenceManager will get closed. In a RESOURCE_LOCAL scenario close on the proxy could be propagated to the real PM before/after deassociation in the Thread-local (why an implementation specific variable ? Is it really needed to be implementation specific ?) In a JTA scenario things get a little complicated. The real PM could be closed by a Synchronization.afterCompletion() registered byPersistenceManagerProxy when it associate the PM with the transaction, but there could be ordering issues with other Synchronization objects referencing the same PM. Looking at the proposed implementation of getPersistenceManagerProxy() in issue JDO-445 I have seen that TransactionSynchronizationRegistry is required and leaving as a value-add the possibility for other env. I can obviously wrong, but I think that the whole feature can be implemented on top of existing impl (well, PMF must support JTA TransactionType in order to work in a JTA-controlled transactions). Is it possible to design an architecture where getPersistenceManagerProxy() delegates to PersistenceManagerProxyProvider ? Is it possible to add to the spec that PMF impl must not rely on a particular PersistenceManagerProxyProvider impl?
Guido
