On Wed, Jun 06, 2007 at 08:45:58AM -0400, Tellier, Stephane wrote: > It could be a problem too for the DSpace web interface : does it means > that every time we access an Item, it creates an instance of this > object and puts it in the cache, and to be never removed as long as > the user's session is still alive? Could someone confirms if that is > actually the case?
Not really, no. It will be cached for the lifetime of the Context object into which it was cached (I think). Contexts are usually created on a per-request basis, so the cache is burned pretty frequently. Naturally, this isn't the case for the indexing and media filters which is probably why that's the only code that uses decache(). > If it is, we should maybe check if the decache() method could be used > more often. It would certainly help large repositories having items > with a lot of bitstreams... I actually disagree with this statement (in the general case). In terms of performance, it is much better to cache as much as possible (provided that the information is accessed multiple times). Reaching into the data layer every time we access an object will get expensive very quickly, so we need to reconcile the two to achieve satisfactory performance. The work I am doing on DAOs separates the in-memory objects from the storage layer entirely (as well as introducing light-weight proxy objects), which should make DSpace "smarter" about what is cached in memory as well. Once this prototype stabilises (soon) I will be doing some simple performance checks to see how this new mechanism compares to the current method. The new layer of indirection I have introduced will itself introduce a performance penalty, but should more than make up for that by being clever (it will also present a much nicer API to code against). cheers, Jim -- James Rutherford | Hewlett-Packard Limited registered Office: Research Engineer | Cain Road, HP Labs | Bracknell, Bristol, UK | Berks +44 117 312 7066 | RG12 1HN. [EMAIL PROTECTED] | Registered No: 690597 England The contents of this message and any attachments to it are confidential and may be legally privileged. If you have received this message in error, you should delete it from your system immediately and advise the sender. To any recipient of this message within HP, unless otherwise stated you should consider this message and attachments as "HP CONFIDENTIAL". ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
