On 13 Mar 2008, at 21:34, Richard Rodgers wrote: > On Thu, 2008-03-13 at 16:23 +0000, Simon Brown wrote: >> I'm still curious about the necessity of the cache, as our removing >> it >> had no noticeable impact on performance and in fact increased the >> responsiveness of the site when we did before-and-after tests with >> Siege. >> > Most of these questions/observations stem from your assumption that > the > cache is there for performance, which it is not (except incidentally). > The primary purpose is (roughly) transactional integrity - ensuring > that > there is only a single copy of an Item, etc, in play before the > Context > commits. In this light, it makes sense that there might be a slight > performance penalty.
So there are instances where, in the course of a single HTTP request, multiple instances of the same Item may (in the absence of the cache) be instantiated, modified, and committed to the database? Could you give me an example of when this could happen? Clearly, as we're currently running without the cache, we're in danger of having this happen, and I'd like to be able to evaluate this risk. From this I'm also assuming that Browse.indexAll() won't do anything to the database until the context commits after the call is done, which for big repositories would be another way for this method to use up a fair amount of heap. -- Simon Brown <[EMAIL PROTECTED]> - Cambridge University Computing Service +44 1223 3 34714 - New Museums Site, Pembroke Street, Cambridge CB2 3QH ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech
