On Wednesday, January 29, 2003, at 10:30 AM, Eric J Kaplan wrote:
Thanks David. You've answered my question. Is this read-aheadI'm not sure about this, you should read the cmp2 docs to find out for sure.
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?
david
-----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 cmpOn 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, therebybypassingYou aren't using the read ahead features properly if this is happening.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 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 ourapplicationon 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 jencksRegards 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 deRupp,HeikoEnvoyé : mercredi, 29 janvier 2003 11:20 À : '[EMAIL PROTECTED]' Objet : RE: [JBoss-user] RE: question about jboss cmpFrom: 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
------------------------------------------------------- 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
