This morning I've released hibernate-memcached 1.0-RC1. This release contains the new Dogpile prevention feature as well as some minor refactoring. If you're using hibernate-memcached, or are even slightly interested in testing out using memcached in combination with hibernate as a second-level cache, you should check this version out.
If you have questions or problems please visit the hibernate-memcached google group.
Saturday, July 26, 2008
Friday, July 11, 2008
Dogpile Prevention for Hibernate-memcached
I posted on the hibernate-memcached project that I was going to release a 1.0-RC1 soon. I will, but first I want to implement one more feature that I think people might like; Dogpile Prevention.
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..dogpile.prevention=true. There is a slight bit of overhead to this is why it won't be on by default. I may make it configurable at the global level as well with something like hibernate.memcached.dogpile.prevention=true.
Once I get this in and tested I plan to release a 1.0-RC1 version of hibernate-memcached.
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.
Labels:
Hibernate,
hibernate-memcached,
Java,
Memcached,
Tech
Wednesday, July 02, 2008
Jt - Java Pattern Oriented Framework
Folks actually built an application framework dedicated directly to GOF software patterns. I'm pretty sure this absolutely what patterns were never meant to be used for. Software design patterns are meant to be applied to specific scenarios were they can be proven to be useful. Not as some golden hammer that when repeatedly bashed into your project will somehow produce the holy grail.
Tuesday, July 01, 2008
A Fantastic Example of REST
I don't know how I've missed Joe Gregorio's "RESTify DayTrader" article. THIS is what REST is all about. Great stuff...
Subscribe to:
Posts (Atom)