Second level cache for java web app and its alternatives

Between the transitions of the web app I use a Session object to save my objects in. I've heard there's a program called memcached but there's no compiled version of it on the site, besides some people think there are real disadvantages of it. Now I wanna ask you. What are alternatives, pros and cons of different approaches? Is memc开发者_如何学JAVAached painpul for sysadmins to install? Is it difficult to embed it to the existing infrastructure from the perspective of a sysadmin?

What about using a database to hold temporary data between web app transitions? Is it a normal practice?

---

What about using a database to hold temporary data between web app transitions? Is it a normal practice?

Database have indeed a cache already. A well design application should try to leverage it to reduce the disk IO.

The database cache works at the data level. That's why other caching mechanism can be used to address different levels. At the java level, you can use the 2nd level cache of hibernate, which can cache entities and query result. This can notably reduce the network IO between the app. server and the database.

Then you may want to address horizontal scalability, that is, to add servers to manage the load. In this case, the 2nd level cache need to be distributed across the nodes. This exists (see JBoss cache), but can get slightly complicated to manage.

Distributed cache tend to worker better if they have simpler scheme based on key/value. That's what memcached is, but there are also other similar solutions. The biggest problem with distributed caches is invalidation of outdated entries -- which can itself turn into a performance bottleneck.

Don't think that you can use a distributed cache as-is to make your performance problems vanish. Designing a scalable distributed architecture requires experience and is always a matter of trade-off between what to optimize and not.

To come back to your question: for regular application, there is IMHO no need of a distributed cache. Decent disk IO and network IO lead usually to decent performance.

EDIT

For non-persistent objects, you have several options:

• The HttpSession. Objects need to implement Serializable. The exact way the session is managed depends on the container. In a cluster, the session is usually replicated twice, so that if one node crashes you still have one copy. There is then session affinity to route the request to the server that has the session in memory.
• Distributed cache. A system like memcached may indeed make sense, but I don't know the details.
• Database. You could of course dump any Serializable object in the database in a BLOB. Can be an option if the web servers are not as reliable as the database server.

Again, for regular application, I would try to go as far as possible with the HttpSession.

---

How about Ehcache? It's an easy to use pure Java solution ready to plug in to Hibernate. As far as I remember it's supported by containers.

It's quite painless in my experience.

---

http://docs.jboss.org/hibernate/core/3.3/reference/en/html/performance.html#performance-cache

This page should have everything that you need (hopefully !)