Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Use Memcached for Java enterprise performance, Part 1: Architecture and setup

How is Memcached different from traditional Java caching?

By Sunil Patil, JavaWorld.com, 04/18/12

Page 2 of 4

Using a traditional Java cache

Using a traditional Java caching framework is quite easy, regardless of whether you choose an open source or commercial option. For an open source framework such as EHCache or OSCache, you would need to download the binaries and add necessary JAR files to the classpath of your application. You might also need to create a configuration file, which you would use to configure the size of the cache, disk offload, and so on. For a caching framework that came bundled with an application server you typically would not have to download any additional JARs because they would be bundled with the software.

Figure 1. Architecture of traditional Java caching (click to enlarge)

After adding support for the caching framework in your application, you could start using it by creating a CacheManager object and getting and setting cache entries in it. Under the hood, the caching framework would create the CacheManager objects in the same JVM where your application was running. Every time you added a cache entry, that object would also be added to some type of hashtable maintained by the caching framework.

If your application server were running on multiple nodes, then you might also want support for distributed caching. In a distributed cache system, when you add an object in cache on AppServer1, that object is also available on AppServer2 and AppServer3. Traditional Java caches use replication for distributed caching, meaning that when you add a cache entry on AppServer1 it is automatically replicated to the other app servers in your system. As a result, the entry will be available on all of your nodes.

Using Memcached

In order to use Memcached for caching you must first download and install the Memcached server for the platform of your choice. Once you've installed the Memcached server it will listen on either a TCP or UDP port for caching calls.

Figure 2. Architecture of Memcached (click to enlarge)

Next, you'll download a Java client for Memcached and add the client JARs to your application. After that, you can create a Memcached client object and start calling its method to get and set cache entries. When you add an object to the cache, the Memcached client will take that object, serialize it, and send a byte array to the Memcached server for storage. At that point, the cached object might be garbage collected from the JVM where your application is running.

When you need that cached object, you can call the Memcached client's get() method. The client will take the get request, serialize it, and send it to the Memcached server. The Memcached server will use the request to look up the object from the cache. Once it has the object, it will return the byte array back to the Memcached client. The Memcached client object will then take the byte array and deserialize it to create the object and return it to your application.

Even if your application is running on more than one application server, all of them can point to the same Memcached server and use it for getting and setting cache entries. If you have more than one Memcached server, the servers won't know about each other. Instead, you'll configure your Memcached client so that it knows all the available Memcached servers. For example, if your application creates a Java object on AppServer1 and calls the set() method of Memcached, then the Memcached client will figure out which Memcached server that entry goes to. It will then start communicating with that Memcached server only. Likewise, when your code in AppServer2 or AppServer3 tries to get an entry, the Memcached client will first figure out which server that entry is stored on, and then communicate with that server only.