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 Sat, 11 Feb 2006 18:02:43 GMT
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.

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.


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: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!

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!

View raw message