On Apr 14, 2008, at 6:08 AM, Rick McGuire wrote:
I've not come up with any clever way of implementing the cache so
far, other than just keeping a list of objects whose primary keys
have not been calculated, and then, if all other lookups fail, start
resolving the primary keys looking for the given target. Not
elegant, but I think this will work.
I do wonder if another approach might work better. If I understand
the reasoning behind the flush, it is necessary because it's
possible that some of the information needed to calculate the
primary key only becomes available after the JPA flush()/merge()
sequence. I suspect for many objects, this is not needed because a
simple primary key is used. Would it be feasible to detect the
situation where a flush is needed to "crystalize" the object to
calculate the primary key? This way, simple object instances where
the primary key is provided in the create() operation would not
experience the performance hit.
Hummm... this is becoming a much more interesting problem.
In the cmp system, the JPA persistence.xml is the master source of
mapping information. In CmpJpaConversion we convert the CMP
declarations in the ejb-jar.xml file to a persistence.xml (JaxB
objects), but a user can provide the persistence.xml file directly
effectively bypassing this code. It should be easy to add a step to
CmpJpaConverstion (or a new DynamicDeployer) that walks the
persistence.xml JaxB objects and notes which beans have generated
primary key fields.
Hopefully knowing which CMP beans use generated primary keys will make
the cache work easier, since you will know that a user can't possibly
ask for an object by primary key when you haven't resolved the primary
key for the user yet.
-dain
