views:

282

answers:

3

We have a large cluster of tomcat servers and I'm trying to find an efficient way to share a count among all of them. This count is the number of "widgets" purchased and needs to be checked for every page view. Any server can complete a sale and increment that count, at which point the new value should be made available to all the cluster members.

We don't want to use the count from the database because there will be many page views between updates across the cluster and a get operation to the db for every page view seems unnecessary.

We have an extensive memcached cluster where we could store the value, get it on every page view, and anyone who updates the value sets the new value to the cluster. This again seems wasteful because of a cache get for each page view.

What I'd like to do is have an in-memory value on each server and a multicast (or similar mechanism) message tell all servers that they just incremented and the new number is X. That would seem to be the most efficient because an action is only taken when update is made, instead of doing work for every page view.

How have you handled this in your applications? Am I over-thinking this... should we just throw it in memcached?

Thanks!

A: 

Both JBossCache and EhCache can operate in UDP multicast mode, replicating an in-memory cache across multiple virtual machines. Unlike memcached, they operate inside the VM, and so a "cache get" is essentially a free operation. They're also pure java, so no needing to maintain a separate cache system.

JBossCache also provides transactions and sync/async operation, so if those are of interest to you, I'd pick that over EHCache.

skaffman
Thanks for the info. EhCache is interesting. Will keep it on my list for the future.
Matt
+1  A: 

Have a look at Terracotta. It gives you a distributed JVM memory model so the value of an object on every box gets update at once.

They have a wrapper around Ehcache, or you can use it transparently to your code with some XML config.

Terracotta provides commercial and open source licenses, and typically, they play down the open source in favour of the commercial -- but the free open source will definitely do what you need and will allow yours apps to scale a very long way.

Jonathan Hedley
Thanks. I like terracotta a lot. We've decided to go with what we have for now, but will be evaluating this for an upcoming project.
Matt
+1  A: 

If you already have a memcached infrastructure, i don't see why you shouldn't use that it'll be ideal for this. Wether it'll be wasteful or another drop in the ocean, only testing will tell you. The architecture will be simple as well, compared to introducing something as intrusive as terracotta or another cache sharing mechanism.

leeeroy
+1 for "Whether it'll be wasteful or another drop in the ocean, only testing will tell you"
Ryan Fernandes
Well, it is wasteful any way you slice it... testing will determine how wasteful. Memcached is obviously the path of least resistance, but I like the in-jvm caching idea for some things. Reading up now.
Matt
We've decided to go the simple route for now and use our memcached. We're going to continue to look at in-jvm cache products, but in the interest of time, we're going to go with what we have for now.
Matt