Re: missing getAll(List keys) method?

[Craig L Russell]

Hi Daniel,

On May 24, 2007, at 11:59 AM, Daniel Lee wrote:

Hi Craig,


here is for internal fetch from data cache.

In the example, when an application issue findAll() for a list of
customers.  It internally, for each customer with order(s), loads the

each item if the relationship to Order is declared as eager.  This is

I think findAll() is different. It is a client level API and the getAll() "eager" relationship (orders) from data cache if they are already cached by calling map.get(orderId) for each order placed by the customer. It again load the items that are related to each order by calling map.get (itemId) for potentially a performance bottleneck and findAll() does not avoid this.

Craig

Seems that this algorithm can be improved to use the broker's findAll mechanism when the instance is not found in the cache. The not-found instances can be found more efficiently than the code currently does.

Thanks.
Daniel


On 5/23/07, Craig L Russell <[EMAIL PROTECTED]> wrote:

Hi Daniel,

Take a look at the findAll(Collection oids) method of
OpenJPAEntityManager. This should do a better job than N get(Object
key) methods.

Craig

On May 23, 2007, at 3:55 PM, Daniel Lee wrote:

> Do we miss the getAll(List keys) method for data cache?
>

> calling get(Object key) multiple time (one for each object in the
> relationship).  For example, it is doing 1 get() call for each
> order placed
> by a customer which we are fetching, that means 100 calls for a
> customer

> getAll(List keys) methods which returns all orders in one call.
> This is
> especially important in a distributed environment.
>
> Is there a way (new plug-in) to avoid the multiple-trip for single
> relationship, or can we implement the code to improve the
> performance in
> this area?
>
> Many thanks.
> Daniel

Craig Russell

> When fetching objects with eager "to-many" relationships, the code is > with 100 orders. The performance can be greatly improved if we have Architect, Sun Java Enterprise System http://java.sun.com/products/ jdo

408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

smime.p7s
Description: S/MIME cryptographic signature