Craig L Russell schrieb:
Hi Jörg,
I realize that this is not the time to get this resolved. Chapter 16
needs to be updated so it's in line with the 220 work (very similar
issues). But we won't finish this in time for JDO2 release this month.
Alright, I was afraid so... So we're trying to support both EJB2 and
EJB3 here?
So, I'm not proposing to change anything in this area at this time.
Let's start discussing it for a maintenance release of JDO that will
issue after both EJB3 and JDO2 are closed.
I just tried to guess when that might be. JDO2's (JSR243) Proposed Final
Draft dates from 12 Aug, 2005, and EJB3's (JSR220) from 21 Dec, 2005. A
very simple guess would be that we can expect at least a half year from
now that the JSR220 specification will be closed. Is anybody familiar
with JSR220 planning, being able provide some better-founded speculation?
Craig
On Feb 11, 2006, at 9:26 AM, Joerg von Frantzius wrote:
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!
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!
