On Wednesday, January 29, 2003, at 08:15 AM, Eric J Kaplan wrote:
No (I wasn't implying it was easy) but without it, for a lot ofYes cache is king. There are two solutions here: all data is in memory, or we cache query results. I have been told the first is fairly easy, and all we would have to do is expose the data to a hypersonic query engine and generate some queries. The second is also fairly easy. We cache results keyed on the ejb-ql and parameters. When when we find a match we, return the results from the cache. When the data changes in any of the query domain we flush the cache. This assumes that the cache can be notified of any changes, which means commit option A until we have a physical store notifications.
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 aThis is an only problem. I am surprised you have not already heard of the read-ahead patches around this.
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).
As for the in-memory query resolver, I thought this was what jdo andJDO is simply an interface to a persistence system. In the end it is all about implementation. We plan on adding support to all of this in JBoss, and transparently to you.
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.
-dain
-------------------------------------------------------
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
