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".
-dain
