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 ofYou 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.
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).
It is entirely possible to implement jdo with no caching between transactions whatsoever. See tjdo on sourceforge.
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.
david jencks
RegardsEric -----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 = Something 2 See! http://www.vasoftware.com _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
