…cache The CacheManager shutdown methods calls dispose on all of the caches which flushes the caches. For more information: http://ehcache.org/apidocs/net/sf/ehcache/Cache.html#dispose()
… cache config
…and fixes a test The type hinting was only added on the calls that are used repeatedly in general caching operations. These should be as fast as possible.... The test fixed was cached-names... It was fine until I added more caches and then the test broke. The test was relying on internal state of the default CacheManager and would thereby be effected by all the other tests. So, I created a new manager jusr for that one test so it won't break everytime a new cache is used in the test. (A better approach probably would be to reset the default cache manager for each test)
… just keys This bug was breaking tests for me beauase my tmp folder had dashed in them. We really shoudn't be changing the values provided by the user anyways.
There were no dependencies specified Copying 3 files to /private/tmp/cache-dot-clj/lib/dev Testing cache-dot-clj.test.cache FAIL in (invalidate-all-external) (cache.clj:23) Second call (50) hits function expected: (check msecs t) actual: false FAIL in (invalidate-all-external) (cache.clj:23) Second call (51) hits function expected: (check msecs t) actual: false Ran 21 tests containing 230 assertions. 2 failures, 0 errors.
Previous to this commit all caches were assumed to be resident in memory for the entire lifetime of the process. This makes since when you are using def-cached or similar. With this assumption it was safe to store all the caches in the internal function-utils* atom. This allowed for easy invalidation of all defiened caches. However, for temporary caches that are bound in a let or binding form you do not want these caches to stick around after there lexical scopiing. This commit allows the client to specify if a cache is intended to be transient and thereby won't be added to the function-utils* atom. This is an okay workaround, but not an ideal solution. The ideal solution would be to not force this extra call onto the client but to always add the caches to function-utils* to keep the API consistent. Instead of storing the objects, WeakReferences would need to be used so that the caches would be GCed as normal. I found this SO thread about similar issues and Google' collections library was brought up as a good option for this type of work: http://stackoverflow.com/questions/3752957/thread-safe-object-pool-with-guarantee-of-returning-existing-object-if-strong-ref
The majority of the time the standard behaviour of using the args as the cache key is fine. However, for complex args (e.g. args which contain Java objects that break identity) you may need to specify how a unique cache key is to be generated from the args. (You may also want to do this for storage/performance reasons.) This commit gives you the ability to specify a cach-key function that operates on the same args which the value is computed from.