On Jun 13, 2008, at 10:52 AM, Rick McGuire wrote:
While looking at some the executeSelectQuery() method in
JpaCmpEngine, I noticed a couple of todo items that I think I'd be
willing to tackle. I do have a couple of questions about how things
work just to make sure I'm understanding things properly.
The first todo is to wrap the result list in a wrapper List can can
do a lazy activation of EntityBean result objects. Am I correct in
assuming that all of the objects in the list will be of the same
type? In other words, if the first result in the list is an
EntityBean, then all of the results are EntityBeans and the list
should be wrappered. Conversely, if the first item is NOT an
EntityBean, then can I assume that the result list can be
immediately returned?
With pure spec defined CMP, yes the collections are always the same
type, but since we allow access to full JPA semantics that is not
guaranteed. In JPA you can have inheritance structures, so for
example, you could query for all vehicles and get back a mixed
collection of Cars and Motorcycles. To make matters worse, we do want
to support the mixing of CMP beans with pure JPA beans in the same
model, which means Car could be a CMP bean and while Motorcycle just a
JPA bean.
The second todo item states "don't activate beans already
activated". How would one detect that situation to bypass the
second activation?
I never figured out a way to do that. One way I can think of is to
maintain a list of all beans activated in the system and which PK they
were assigned during activation. Unfortunately, that would mean we
would once again be double cache CMP engine. The lac of cache in the
JPA CMP engine makes it very simple and efficient, since the entire
cache can be managed by the JPA implementation.
The only other possible implementation I can think of is to add an
additional field to the generated subclass that contains the PK
assigned during activation. Then the engine could check if the new PK
is different and reactivate. This would make the generated class and
the activation logic a bit more complex, but the real pain for me is
it would make supporting direct CMPs where we don't generate a
subclass at all. This is not something we support right now, but
something I'd like to support in the future.
I suggest you attack the streaming result sets first, ignoring the
activation issue, since streaming should have the biggest performance
improvement.
Oh ya, you may want to take a look at CmrSet as it contains logic to
proxy and unproxy CMP beans. Queries are bit more difficult as you
have to support Remote interfaces in addition to Local interfaces, but
I think the same basic logic applies.
-dain
