Hi, a recent thread on dspace_tech [1] got me thinking about my previous
experiences with caching, in other web development environments. In
particular, a few years back, I did a lot of development using a PHP-based
framework called ezPublish, and it had a caching scheme that could, on
occasion, be
Hi Hardy,
I've used the "clearcache" functionality on our production site, and it is
useful for performing manually, when your site is just stuck. I think it
would be best to hide the url in a location that public users can't access
/protected/clearcache, just because they shouldn't have access to
IMO I think that while I originally proposed this solution, it may not
completely undo our current problems. the following changes introduced a
behavior into the XMLUI that no longer allows the page to state it has
changed because the following selector preempts this process and forces
response he
I have noticed that, in contemporary languages with easy dynamic
allocation and garbage collection, we wind up with a lot of "caches"
that aren't caches in the traditional sense, but baskets that fill
slowly and endlessly with everything we've ever seen. This approach
(e.g. allocate a HashMap and
All,
Just a brief note, for those who are not aware -- the "clearcache"
functionality that Peter talks about is now built into DSpace 1.8.0 (and
its URL is only accessible to DSpace System Admins). You can kick it off
via the Admin UI Control Panel. See:
https://jira.duraspace.org/browse/DS-96
