Hello Craig,
the problem is with code that manages PersistenceManagers and
transaction demarcation itself, i.e. code without session beans, that is
run inside an application server (I can give an example if required). If
the semantics of PMF.getPersistenceManager() suddenly change
substantially, just because the code now runs within an application
server, it can easily break (again I can give examples if required).
That kind of code might in particular keep PersistenceManagers open for
the whole lifetime of the server, which would be in contrast to the
demanded "At the end of the business method, the PersistenceManager
instance must be closed."
How about a method PMF.getManagedPersistenceManager(), or
PMF.getPersistenceManagerFor(EnterpriseBean caller), explicitly for
managed code? A session bean expects transaction boundaries and (real)
PM lifecycle to be managed, and that's entirely different from what the
original PMF.getPersistenceManager() delivers.
Regards,
Jörg
Craig L Russell schrieb:
Hi Joerg,
On Feb 10, 2006, at 3:42 PM, Joerg von Frantzius wrote:
Hi Craig,
please see my comments below.
Craig L Russell schrieb:
Javadogs,
While reviewing the spec in some more detail prior to closing it for
the release, I noticed that there is a corollary to the requirement
that
"after close(), all methods that actually do anything must throw
exceptions. "
So if a PM is closed and put back into the pool, it can never be
given out again because it needs to be opened. This violates the
requirement that after close, all methods throw exceptions.
The problem can be avoided by using proxies (that are permanently
closed by close()) and giving the proxies to the user. The proxies
can be garbage collected and the proxied PersistenceManager can be
put back into the pool when the proxy is closed.
Doesn't that again mean
"JDOHelper.getPersistenceManager(pm.getObjectById (pc)) != pm",
which, according to Abe White, is a broken system?
If it will make people happy, I'll add the requirement
that JDOHelper.getPersistenceManager(pm.getObjectById (pc))
.equals(pm) but not ==. We have never had anything like the identity
of a PersistenceManager exposed by the specification.
This is from 16.1 in the JDO spec:
<spec>
Stateless Session Bean with Container Managed Transactions
Stateless session beans are service objects that have no state between
business methods. They are created as needed by the container and are
not associated with any one user. A business method invocation on a
remote reference to a stateless session bean might be dispatched by
the container to any of the available beans in the ready pool.
Each business method must acquire its own PersistenceManager instance
from the PersistenceManagerFactory. This is done via the method
getPersistenceManager on the PersistenceManagerFactory instance. This
method must be implemented by the JDO vendor to find a
PersistenceManager associated with the instance of
javax.transaction.Transaction of the executing thread.
At the end of the business method, the PersistenceManager instance
must be closed. This allows the transaction completion code in the
PersistenceManager to free the instance and return it to the available
pool in the PersistenceManagerFactory.
</spec>
We never put more detail into this section to specify how the PM can
be closed and the underlying PM still stay open in order for the
persistence context to be propagated (EJB3 terminology). But nothing
in the proposal invalidates Chapter 16.
Possibly that discussion already existed and I'm saying something
stupid, but what about a new open() method and all operations
throwing exception after close(), except for open()? I'd also find
that more in line with accustomed operations on poolable objects anyway.
No, pooling APIs are not usually exposed to the user. It's usually in
an SPI.
Craig
Take a look at this proposed clarification that describes
PersistenceManagerFactory.getPersistenceManager.
<proposed>
This method will never return the same instance as was returned bya
previous invocation of the method. Note that this implies that
pooled implementations must use proxies and not return the pooled
instance directly from the pool.
</proposed>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
