db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg von Frantzius <joerg.von.frantz...@artnology.com>
Subject Re: Issue 158: Specification clarification 11.3
Date Sat, 11 Feb 2006 19:15:48 GMT
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: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!
>
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message