|Anonymous | Login | Signup for a new account||09-21-2023 05:30 PDT|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details [ Jump to Notes ]||[ View Advanced ] [ Issue History ] [ Print ]|
|ID||Category||Severity||Reproducibility||Date Submitted||Last Update|
|0000289||[Resin]||minor||always||06-29-05 00:00||11-30-05 14:43|
|Summary||0000289: amber list query's only cache the first 25 records of a result set|
after stepping through the resin code for many hours, I have discovered why it seems like many of our cmr/ejbSelect queries don't get cached. throughout the amber source code, there is a hard-coded limit of only the first 25 records of a result set getting cached in a "CacheChunk".
Specifically, the classes include com.caucho.amber.query.UserQuery, com.caucho.amber.query.ResultSetImpl, com.caucho.amber.connection.AmberConnectionImpl, etc.
Why was this limit set? If a one-to-many cmr relationship has more than 25 records in it, the first 25 records are cached, but then the 26th record is asked for, it always re-executes the query, etc. on *every* load.
It appears from my dissection of the source code that some structure was put in place to cache multiple "chunks" of a result set. eg. the first 25 records in the 1st chunk, the 2nd 25 in another chunk ... so as to only cache what is necessary. however, the implementation only ever sets a cachechunk for the first 25 records and after that always goes back to a new queried result set.
though it is nice that amber can now cache custom ejbSelect results, resin 2.x was able to cache the entire cmr record set. we can't migrate to resin 3 until we can cache an entire result set. otherwise our database servers will be swamped and our system will fall over.
|Additional Information||resin 3.x pro, all platforms|
|06-29-05 00:00||user241||New Issue|
|11-30-05 00:00||administrator||Fixed in Version||=> 3.0.15|
|11-30-05 14:43||ferg||Status||resolved => closed|
| Mantis 1.0.0rc3[^]
Copyright © 2000 - 2005 Mantis Group
33 total queries executed.|
27 unique queries executed.