Hi, It doesn't have to be one or the other. Sometimes it makes sense to use both memcached and an in-process cache. The in-process cache will be faster, but you then have to think about memory usage and cache consistency. If you have some keys which are fetched more frequently than most, it may make sense to try fetching from the in-process cache first and then from memcached. Personally I've used ehcache (with cache distribution via RMI) and memcached, and the combination worked well for me - whether I used ehcache, memcache or both together really depended on the use case. This is a off-topic for this list, but regarding ehcache, I've tried using JGroups distribution with ehcache, but ran into problems with it, but RMI with multicast cache peer discovery is mature. The RMI distribution gets expensive if you have a large number of boxes though since each cache has to talk to all its peer caches.
Hope that helps. Cheers, John On Fri, Oct 9, 2009 at 7:24 AM, samr <[email protected]> wrote: > > Basically when a user requests for an artifact, the backend makes > several webservice calls to build the response. > A few responses from these webservice calls will not change over a > period and would like to cache this in case > customer comes back again with the same request. > > > On Oct 9, 2:05 am, Dustin <[email protected]> wrote: > > On Oct 8, 11:30 pm, samr <[email protected]> wrote: > > > > > memcached is in C and hence would be faster. > > > > C doesn't necessarily mean faster. Many of them have at least an in- > > process offering which will probably perform like a java.util.Map with > > a mutex (with maybe a bit more overhead) when running in a single-node > > configuration. > > > > That is to say, not running a C program will be faster than running > > a C program. > > > > My java client (http://code.google.com/p/spymemcached/) offers a > > java.util.Map interface to memcached which will give you an easy kv > > store while allowing you to scale your memory independently of your > > JVMs. (though, I tend to write more to the memcached interface and > > not the Map interface). > > > > There are trade-offs. > > > > > On feature wise the java solutions seem to be offering a lot. > > > > A piece of software with a long list of features means that the > > features that you care about make up a smaller percentage of the > > product. That doesn't necessarily speak to quality, but it at the > > very least makes me care less about choosing a product based on > > features going too far beyond my own requirements. > > > > > Please suggest what should be considered in choosing the right option. > > > > Based on the requirements you've stated, I'd suggest stating more > > requirements. :) >
