On 7 Aug 00, at 16:49, thierry janaudy wrote:
> Hello,
>
> I would like your opinion on the following.
> I have a method defined in the life-cycle interface of an entity
> bean which returns a large collection of pks (severeal hundreds,
> potentially thousands).
> I habe to go through all the objects, so the app server does
> an ejbLoad for each pk, so several thousands ejbLoad.
> Perf is crap. Session bean with JDBC code a lot faster obviously
> because I do a SELECT * and that's finished. With the entity bean
> I have a remote call + SELECT * ... WHERE PK=MyPK...
>
> Do you think it would be nice to have a cache on the app server so that
> for a findLargeXXX, the app server creates EJBobjects instances the
> first time, and do not go to the database when I am dealing with them.
Hi Thierry,
I agree that a cache is appropriate here, but I would cache the
results of the select statement and use that cache as the entities
are instantiated, rather than caching actual EJBObject instances.
Otherwise the container is potentially doing unnecessary work (e.g.
if the business logic doesn't require iterating through the entire
result set or if the first access throws an exception). The
performance hit is in database access, so caching the results of
the select statement should solve this problem.
-Dan
>
> It implies to have a smart and nice cache in the app server.
>
> What do u think gurus?
>
> -- Thierry
>
