On Wednesday, January 29, 2003, at 09:30 AM, Eric J Kaplan wrote:
All tuning options are vendor specific. You should really read the EJB specification. Specifically pay attention to what they don't address. For example, all physical store mappings and tuning are out of the spec.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 thatCurrently JBoss always goes back to the Database for the primary keys. A query cache is on the todo list for 4.0 and an in-memory query engine may also make it.
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?
As for caching between transactions it depends on the commit option. I have code in 4.0 (just haven't gotten to the back port yet) that merges the transaction cache in the main cache after the tx commits, but this only works with commit option A, as B and C always throw out the cache data when the new transaction starts. We hope to address that with Optimistic locking in 4.0.
-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
