db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: Issue 158: Specification clarification 11.3
Date Fri, 10 Feb 2006 23:55:37 GMT
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:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!
>>
>

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!


Mime
View raw message