In Java spring, How exactly mem cache and Ehcahe stores data in server memory?A simple explanation or comparison would be helpful.
The best way to find the internal workings of a caching framework is to go through its source code. I could not find any authoritative article detailing the internal working of these frameworks. Here are few points which differentiates Ehcache from Memcache.
Distributed caches like MemCache and EHcache work like a Giant Hashmap. By Distributed, it means that the cache can be spread over multiple servers, virtually extending the storage capability to unlimited number of objects.
Although, both Ehcaceh and Memcached appear like a hashmap, the way they work is quite different.
Ehcache is general purpose Java Object cache, meaning generally used with the Java Application to cache java objects. Its generally used as an add-on to the application for caching requirements.
Ehcache is completely written in Java so its a pure Java application.
Ehcache offers RESTful APIs as an interface.
Memcached is a general purpose cache for caching any type of objects.
Its a client-server based scheme. So you have a memcached server which holds the actual data and there are clients (available in almost all the languages). The Memcached Server is written in native language(C/C++).
For using with Java, it needs a memcached client (spymemcached)
I know I have not answered your core question regarding the internal working of the cache frameworks but the points I mentioned should help you select one over other based on your requirements.
Related
I wish to compare the Read, Write and Read/Write speed for a burst of data on the following caching platforms:
EhCache
Redis
MemCached
GemFire
JCS (Java Caching System)
How can I do so? How can I make use of platforms like Spring and/or Hibernate in doing this?
Short answer: Just implement an example application and compare the speeds.
Long answer: The products you mention are very different. You can use them in different usage scenarios. E.g. I would roughly categorize it as follows:
Inside Java heap: JCS, EhCache
Off Java heap: MemCached
Distributed: Redis
Persistent: Redis
I left out GemFire, since I don't know anything about it.
Also you cannot do a direct comparison since the APIs are very different. For redis and memcache you use a rest interface. Theoretically it should be possible to implement for every product a JSR107 like API, so you can run a single test on the products. But again, that is senseless, since the products serve different purposes. For a real solution, it might be better to combine redis and EhCache. One solution for scaling and persistence, one solution for handling the caching part for Java objects within the Java heap.
I have done some benchmarking of Java caches. However it just covers the inside heap part, and runs only single threaded, so there is need for extension. For an entry look on the cache2k benchmarks page. The benchmark code is on github and runs OOTB. If you want to contribute to it, you're very welcome!
I suggest to use JMeter, where you can create some jobs to test the functionality of you application and create some Benchmarks.
http://jmeter.apache.org/
I am implementing a memory caching system for a web application. This memory caching system will have to handle objects sized from small scale to large scale and more and more hits to caches (reads and writes) . The system will have to handle multiple cachinng services such as JCS, ehCach, Memcach, SQL caching etc based on the configuration.
For learning and studying purposes and to implement a better architecture for my system, any one please let me have some resources. (example: sample class diagrams with project source files ).
The question is totally unspecific! The best thing you can do is to work through the tutorials, examples and manuals of the caching solutions.
You should also consider distributed caching solutions like infinispan and hazelcast.
For in-memory only caching Guava Cache and cache2k (I work on cache2k) might be sufficient.
If you start a new architecture around caching I strongly suggest that you look into the JSR107/JCache spec, because this is the new standard way to access caching services.
Running a last db server jersey applications and I need to start thinking about memory caching.
The majority of the db commands are only updated once a day. There is an opportinity to cache these queries at the server level.
What options do I have? I know quite a few large applications use memcached. Others??
Any of the Java memcached libraries is probably your best best.
Spymemcached
Memcached-Java-Client
Xmemcached
Memcached is a good default. Redis can be used to. It offers richer functionality should you choose to use it, but if you're use case will always be what memcached offers then there's no particular advantage.
Note that PostgreSQL has an internal cache (the buffer cache) and uses the kernel's disk cache. So tuning the PostgreSQL config for your needs may be a good idea.
In addition to this you could use materialized views for some queries.
I'm looking for a solution to share a cache between two tomcat web apps running on different hosts. The cache is being used for data synchronization, so the cache must be guaranteed to be up-to-date at all times between the two tomcat instances. (Sorry, I'm not 100% sure if the correct terminology for this requirement is "consistency" or something more specific like having ACID property). Another requirement is of course is that it should be fast to access the cache, with about equal numbers of writes as reads. I do have access to a shared filesystem so that is a consideration.
I've looked at something like ehcache but in order to get a shared cache between the webapps I would either need to implement on top of a Terracotta environment or using the new ehcache cache server. The former (Terracotta) seems like overkill for this, while the cache web server seems like it wouldn't provide the fast performance that I want.
Another solution I've looked at is building something simple on top of a fast key-value store like Redis or memcachedb. Redis is in-memory but can easily be configured to be a centralized cache, while memcachedb is a disk-based persistent cache which could work because I have a shared filesystem.
I'm looking for suggestions on how to best solve this problem. The solution needs to be a relatively mature technology as it will be used in a production environment.
Thanks in advance!
I'm quite sure that you don't require terracotta or ehcache server if you need a distributed cache. Ehcache with one of the four replication mechanisms would do.
However, based on what you've written I guess that you're looking for more than just a cache. Memcached/Ehcache are examples of what you might call a caching layer for your application - nothing more.
If you find yourself using words like 'guaranteed' 'up-to-date' 'ACID' you're better off using an in-memory DB like Oracle Times Ten/MySQL Cluster/Redis with a disk-based persistent storage.
You can use memcached (not memcachedb) for fast and efficient caching. Redis or memcachedb could be an overkill unless you want persistent caching. Memcached can be clustered very easily and you can use spymemcached java client to access it. Memcacached is very mature and is running in several hundred thousands, if not millions of production servers. It can be monitored through Nagios and Munin systems when in production.
Is Terracotta a distributed cache?
Although you don't specify which product you are talking about, I'm going to assume you mean the open source platform itself. The short answer is no, but it can be used to write a distributed cache, and it has been in one of their own products (Ehcache).
You can see an overview of what the core engine is about here (it seems that they are hiding the information on their open source platform behind a registration wall now). It is a clustering engine that does not use J2EE technology, and its main purpose is to simplify distributed computing development. Besides caching, obvious use cases involve high availability and scalability needs. Think of it as enabling relatively plain java code to run "in the cloud" without having to worry about a lot of the details that that might involve.
Terracotta has nothing to do with 'caching' although most implementations use it for caching purpose.
Terracotta is about clustering and the terracotta itself is implemented using java (to my knowledge).
How Terracotta achieves clustering:
1) JVM1 running APP
2) JVM2 running APP (same)
3) JVM3 running APP (same)
Without Terracotta all JVMs are running independently with out knowing about each other performing some redundant tasks and maintaining their independent heaps
When you enable Terracotta (a Terracotta server running) across these 3 JVMs (configured to use Terracotta server)
Terracotta gives a logical view of all 3 JVMs as a single JVM. Any object graph that you designate to be stored at Server(Root ) is available to all 3 JVMs just like any local object but each JVM can can read/write to that object, whose changes are immediately(~) available to the other JVMs.
For this very reason Terracotta is used mainly for caching and distributed computing as idle JVMs with no work can process the work of the heavily loaded lagging JVM if the unit of work object is designated to be shareable.
Your question is unclear (Terracotta has several products) but yes, the Terracotta Platform does offer a solution for Distributed Caching.
L2 cache is the one that is external to a processor (a JVM, in our case) and shared among them. Serving as a transparent L2 cache, Terracotta combines your multicomputer into a multiporcessor. Thus, it is a distributed cache. But, you seem not to get it because you are SW guys who have never imagined that it can be transparent. You expect that a cache is a thing that has get/set methods and coherence problem that you need to resolve at application level.
Read the "Definite Guide to Terracotta". The authors are literal saying that Terracotta is a distributed cache. I think they understand this better than anybody who says "no" replying here.