On Apr 9, 2007, at 12:41 PM, Patrick Linskey wrote:
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.
... but it's not the JPA-visible itself that is necessarily going
to be
heavyweight, these days. Maybe the proxies shepherding the instance
through the CMP lifecycle will be heavyweight, or certain fields in
the
instance sourced from JNDI.
My point is that if you're seeing a performance penalty from creating
the actual instances themselves, I'd be interested in knowing what it
is, because potentially we could address that problem directly. If the
penalty is some other parts of the instantiation process, or the
fetching of the data from the database, well, that could be less
resolvable.
When a CMP instance is created there are two callbacks
setEntityContext (the entity now exists) and activate (the entity now
has a primary key). Both of these callbacks are allowed to lookup
stuff in JNDI like EJBs and JDBC connections. Some applications
cache lots of data and some even cache data from databases. So it
could be very expensive.
For most apps, these callbacks are empty.
How are you coding the interaction between the (oh-so-wonderfully-
named)
commit options and the JPA data cache?
I'm not because my implementation didn't work. I tried to implement
them by keeping cache of instances. Then when an instance if
fetched, I would check the global cache, and if there was an instance
available, I would call merge. Then if commit option B, I would do a
refresh (reload?). The problem was that merge returned a new
instance making my global cache useless.
-dain
