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