If you're only running 2 or 3 instances of your application this really isn't a problem. If you're running 42 instances there is the risk of a "dogpile". If a frequently used item drops from the cache after it's expiration time comes up you run the risk of many instances of your application working concurrently to restore the cached data. Each instance overwriting the other instances attempt to update the cache until everyone sees the data is no longer missing. Other caching systems attempt to remedy this with locking. That's a really bad thing most of the time for scaling as you'd never want to have all the instances of your application synchronized on what one of them is doing.
To remedy this in hibernate-memcached I will follow the patterns mentioned in the article above. This new feature will go in as a configurable option that is, by default, turned off. I plan to make it configurable per cache-region so enabling it would look like hibernate.memcached.
Once I get this in and tested I plan to release a 1.0-RC1 version of hibernate-memcached.
No comments:
Post a Comment