I am trying the new ehcache version but I noticed that, apparently, there are no search APIs.
Is this normal or am I missing something? Documentation says nothing about that.
The main reason is that searching in a cache has very strange semantics in the face of expiry and eviction. Since Ehcache 3 is focusing on what it is good at - the caching use case - we decided to shave some features that are more targeted at the storage use case.
Related
Does the Linq2DB ORM support query result caching - first level or second level? I noticed the namespace LinqToDB.Common.Internal.Cache, does it mean caching has to be built by the consuming application through a custom caching manager?
Well, linq2db is designed to work with queries not object management. Caching is a very specific case which introduces a lot of side effects. For example if you change some field and the cache contains such records - you have to invalidate the cache, otherwise the system will return obsolete data. Invalidating caches is the most difficult part here.
Anyway there are third party libraries which can do that for you:
LinqCache
Probably there are other libraries which can do similar things.
I am trying to find the new best practice for clearing statistics on an ehcache Cache. Previously, you would be able to call clearStatistics() and then you coul in real-time reset your stats on hit/miss operations.
Somewhere between ehcache 2.6 and 2.10, this went away. However instead of seeing a release where it was deprecated and hints as to the new philosophy or suggested implementation strategy, I simply see the method gone from the API documentation: It is not shown in http://www.ehcache.org/apidocs/2.10/deprecated-list.html#method nor http://www.ehcache.org/apidocs/2.9/deprecated-list.html#method, and any previous versions are lost to refactoring on the site.
Cache.clearStatistics has been removed in Ehcache 2.7.0. This release included a large rework of the Ehcache statistics to make them low overhead and ensure you paid the price only for statistics you queried and only for a limited period of time.
You can't clear statistics anymore inside Ehcache. If you need that feature, you have to use an external object that can handle the baselining for your application.
You can find the API documentation for each <major>.<minor> on http://www.ehcache.org/documentation/. And for the most recent versions, you can navigate to different fix versions even though there is no explicit link.
For example, see http://www.ehcache.org/apidocs/2.9.1/index.html
Disclaimer: I am working on Ehcache
We're going to migrate our application from eXist-db 1.4.1 to ~2.2 (probably RC2).
I`m wondering if anybody already did such a migration and what impediments they met?
I already found some documentation about this on official website and tried to Google, but didn't find much. For now I know that there were significant changes in the security model and some APIs are also changed. But still I want to know if somebody investigated further or maybe can share success story.
The main difference between 1.4.1 and 2.1/2.2 is that stored XQueries now need the executable flag to be set. You can fix your permissions automatically using a query as described in the documentation.
It is also possible that some of your existing queries report errors on 2.1/2.2, which they did not before. In nearly all cases this happens because 1.4 was less strict about the XQuery specification and processed expressions which should not be allowed (the standard as well as the implementation evolved). Also, the query engine may now do additional checks to prevent potential issues. Usually the error messages by the compiler should directly lead to the code you have to fix. This may cost a few minutes, but it's worth the effort. Apart from this, no particular migration issues have been reported.
I noticed that Spring reference application (Sagan) uses the SimpleCacheManager implementation. See here for source code of Sagan.
I was surprised by this choice because I thought that all but small applications running on a single node would use something like a Redis cache manager and not the simple cache manager.
How can a large application like Sagan -which I assume runs on cloudfoundry- use this simple implementation?
Any comment welcome.
Well, the SimpleCacheManager choice has been made because it was the simplest solution that could possibly work. Note that Sagan is, at least for now, not storing a lot of data in that cache and merely using it to respect various APIs rate-limiting and get better performance on some parts of the application.
Yes, Sagan is running on CloudFoundry (see this presentation) and is using CF marketplace services.
Even if cache consistency between instances is not a constraint for now, we could definitely add another marketplace service, here a Redis Cloud instance, and use this as a central cache repository.
Now that we're considering using that cache for more features, it even makes sense to at least consider that use case, since it could lower our monthly bill (pay a small fee for a redis service and use less memory for our CF instances).
In any case, thanks a lot balteo for this insightful question, we've created a Github issue for that.
We're using the Enterprise Library Caching Application Block to do caching (in memory) in our web service. Works great, no complaints.
We're starting to do some load testing, and I've been asked to disable the cache so we can get some relative idea of what kind of performance gain caching gives us. I thought this would be simple - it turns out its not.
I can't find any configuration setting to disable the cache. I suppose I could turn down the maximumElementsInCacheBeforeScavenging setting, but is there a better way?
I found one post that suggests creating your own Cache Manager that does nothing - again, is there a better way to do this?
Your best bet is to provide a custom implementation of ICacheManager (interface added in Entlib 4, can't help for earlier ones) that doesn't store anything and never gives a cache hit. Then you configure the block to use your "NullCacheManager" or whatever you want to call it.