I am unclear as to if you are doing actual manipulations with the instances
(calling methods on them) or merely returning the list of keys.
If it is the latter, I would declare the key as a type and treat it as a
value object. Then in the home interface for a stateless session bean, you
would have a getKeys() method which would return you a Vector of key
objects. You can make the objects immutable so as not to imply that changes
to the returned key instances would be reflected in the database.
Then, in your implementation of getKeys, you can do a "SELECT KEY
FROM......" iterate through the result set and populate the Vector.
----- Original Message -----
From: "marc fleury" <[EMAIL PROTECTED]>
To: "jBoss Developer" <[EMAIL PROTECTED]>
Sent: Monday, August 07, 2000 11:16 AM
Subject: RE: [jBoss-Dev] findLargeXXX and caching at the App Server level
> Relax,
>
> let people discuss it a bit, i am interested in seeing it
>
> marc
>
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of thierry janaudy
> > Sent: Monday, August 07, 2000 9:11 AM
> > To: 'Dan OConnor '; 'jBoss Developer '
> > Subject: RE: [jBoss-Dev] findLargeXXX and caching at the App Server
> > level
> >
> >
> > Thx Dan,
> >
> > so can we add that on the TO DO list of jBoss?
> > Is it part of the JAWS work?
> >
> > -- T
> >
> >
> > -----Original Message-----
> > From: Dan OConnor
> > To: jBoss Developer
> > Sent: 07/08/00 17:03
> > Subject: Re: [jBoss-Dev] findLargeXXX and caching at the App Server
level
> >
> > 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
> > >
> >
> >
> >
> >
>
>
> -------------------------------------------------------------------------
> This email server is running an evaluation copy of the MailShield anti-
> spam software. Please contact your email administrator if you have any
> questions about this message. MailShield product info: www.mailshield.com
>
-------------------------------------------------------------------------
This email server is running an evaluation copy of the MailShield anti-
spam software. Please contact your email administrator if you have any
questions about this message. MailShield product info: www.mailshield.com
