Thanks David. You've answered my question. Is this read-ahead capability a specific feature of jboss or in the spec? One issue we have is that as much as we push jboss, we have installs where they for whatever reason aren't using jboss.
About read-ahead. If I enable it, and I execute an initial finder that reads ahead and caches, and then someone else comes, my understanding is they still have to go back to the db to find primary keys. Will they also read ahead as well? If so, aren't they grabbing extra data that's already in memory? -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Wednesday, January 29, 2003 9:51 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-user] RE: question about jboss cmp On Wednesday, January 29, 2003, at 09:15 AM, Eric J Kaplan wrote: > No (I wasn't implying it was easy) but without it, for a lot of > applications going through the entity beans isn't practical. More > often > than not, the applications we work on do NOT simply findByPrimaryKey, > but instead need to load based upon a query. I take what Mark Fleury > says in his paper to heart about taking advantage of the cacheing > capabilities of the container, but not if I have to go to the database > anyway to find all the primary keys every time... > > We've found anytime we've had slowness in our application, it's a > session bean going through an entity bean's home interface to find a > bunch of beans, and we have to change to direct jdbc, thereby bypassing > the container. This is not JBoss specific, it's a general problem. > Bottom line is, for mostly read-only apps with limited write, entity > beans can be overkill. Yes, there is a speedup if the beans are > already > in memory of just going to the db to find the primary keys and then > pulling the data from the beans already in memory, but the penalty one > has to pay if the beans are NOT in memory is severe (one by one, the > container goes back to the db to grab each row). You aren't using the read ahead features properly if this is happening. You can configure jboss to, roughly speaking, read everything into one multi-row result set. > > As for the in-memory query resolver, I thought this was what jdo and > jdo-ql were all about? We have to do similar things in our application > on the client side for holding onto local copies of objects and > limiting > unnecessary calls back out to the app server to get new objects. It is entirely possible to implement jdo with no caching between transactions whatsoever. See tjdo on sourceforge. david jencks > > Regards > > Eric > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] On Behalf Of Sacha > Labourey > Sent: Wednesday, January 29, 2003 5:27 AM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-user] RE: question about jboss cmp > > Well, that would involve: > - loading all potential beans in memory first > - having an in-memory query resolver (able to resolve SQL queries > in-memory) > > You want to do it? ;) > >> -----Message d'origine----- >> De : [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED]]De la part de > Rupp,Heiko >> Envoyé : mercredi, 29 janvier 2003 11:20 >> À : '[EMAIL PROTECTED]' >> Objet : RE: [JBoss-user] RE: question about jboss cmp >> >> >>> From: David Jencks [mailto:[EMAIL PROTECTED]] >> >>> AFAIK only findByPrimaryKey queries are optimised to look first in >>> memory. All others at least fetch the pk values from the db. >> >> Will this change in the future? Perhaps not in an automated way, >> but by specifying that a certain finder should first look in memory? >> >> -- >> Bancotec GmbH EMail: [EMAIL PROTECTED] >> Calwer Str. 33 Telefon: +49 711 222 992 900 >> D-70173 Stuttgart Telefax: +49 711 222 992 999 >> Ein Unternehmen der Cellent AG http://www.cellent.de/ >> >> >> >> ------------------------------------------------------- >> This SF.NET email is sponsored by: >> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! >> http://www.vasoftware.com >> _______________________________________________ >> JBoss-user mailing list >> [EMAIL PROTECTED] >> https://lists.sourceforge.net/lists/listinfo/jboss-user >> > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > JBoss-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-user > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld Something 2 See! > http://www.vasoftware.com > _______________________________________________ > JBoss-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-user > ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld =omething 2 See! http://www.vasoftware.com _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
