openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: Can I reuse instances?
Date Wed, 11 Apr 2007 01:18:59 GMT

On Apr 10, 2007, at 1:24 PM, Craig L Russell wrote:

> Hi Dain,
> On Apr 10, 2007, at 12:58 PM, Dain Sundstrom wrote:
>> On Apr 9, 2007, at 5:44 PM, Craig L Russell wrote:
>>> Hi Dain,
>>> On Apr 9, 2007, at 11:10 AM, Dain Sundstrom wrote:
>>>> On Apr 8, 2007, at 1:56 PM, Craig L Russell wrote:
>>>>> Hi Dain,
>>>>> I haven't looked in detail at the life cycle of CMP beans in a  
>>>>> couple of years, but in general you can't simply keep the state  
>>>>> of the underlying Entities through the life cycle. CMP beans  
>>>>> are pooled and reused in transaction contexts and you have to  
>>>>> load the state at specific points in the life cycle.
>>>> It depends on the commit option the container is using.  In  
>>>> commit option A, you assume the cmp engine is the sole user of  
>>>> the database, so you don't need to load.  Normally people use  
>>>> commit option B where you keep instances activated with a  
>>>> specific primary key and reload the data in each tx.
>>>>> Using the primary key stored in the CMP bean to do em.find at  
>>>>> the appropriate time is the obvious way to take advantage of  
>>>>> the em second level cache. To the extent that this is not  
>>>>> efficient, we should fix it in the JPA layer not the CMP layer.
>>>> I would prefer to keep as much of the CMP stuff on the CMP side  
>>>> as possible so the JPA implementation can focus on JPA issues.    
>>>> One of the assumption of JPA is that entities are light weight  
>>>> and cheap to create, so you take the safe route and construct a  
>>>> new one when every you need an instance.  In CMP the assumption  
>>>> is that entity instances are expensive to create, so less safe  
>>>> route and you pool them.  Reusing instances is really a CMP  
>>>> problem, but I don't think it can be implemented without the  
>>>> help of the JPA engine.
>>> I'm afraid we're getting wrapped around the axle on definitions.  
>>> Here's what I'm trying to get across:
>>> CMP Entity Beans are expensive to create and there's a lot of  
>>> required behavior to manage them. You pretty much have to  
>>> implement the life cycle in the spec. It's your choice how to  
>>> implement the "state" part of the beans. You can use wrappers  
>>> around various kinds of state objects like ResultSet or generated  
>>> classes that contain fields with the state.
>>> Your implementation uses JPA Entities to hold the state. These  
>>> JPA Entities are not at all specified by CMP Entity Beans. JPA  
>>> Entities as cheap to create so all you need to do is hold on to  
>>> the ids and when you need state from the database, ask JPA  
>>> EntityManager for the state. If the state is already in the  
>>> second level cache, this is very cheap to access.
>> In my implementation the CMP entity is the JPA entity.  They are  
>> the same object.  There are no "state holders".
> Now I understand. I don't think the design works, from lots of  
> different perspectives.
>> We choose this design to easy the transition from CMP to JPA but  
>> has the drawback that we are completely reliant on the JPA  
>> implementation for instance management.
> I don't think the design can work. The CMP protocol requires  
> separating the CMP instance from its state. You are generating the  
> CMP concrete implementation class as part of deployment, and the  
> concrete class needs to contain state or a reference to state. My  
> experience is that keeping state directly in the CMP bean isn't  
> likely to work well.
> Sorry for the distracting comments. I didn't imagine that you were  
> trying to directly persist CMP beans.

I can assure the design "works".


View raw message