One of the things we see a lot in the context of usage from Hibernate is contention due to puts into the cache which logically are not writes. The scenario I am talking about is when Hibernate loads some data from the database and then places that into the second level cache. After Hibernate loads this data from the database, it then does a put into the cache. JBossCache interprets that as a write and issues a write lock. This is what I see as the referenced mismatch. Cache considers itself as the "truth" of the system so far as data state is concerned. However, at least in this usage, that is clearly not the case; the database is the "truth". What really *should* happen in this scenario is for JBossCache to instead acquire a read lock on the created node (unless the user specifies some form of write lock in the db, in which case we may want to also acquire a write lock in the cache; but that's a whole other discussion). So I have given some thought about how to best resolve this. I first thought through using current JBossCache concepts. Like loaders. I think loaders might actually work, except for the fact that they are static for the whole cache instance; for that approach to work for us, we would really need to be able to specify a loader *per invocation*. Next (and to my mind the most viable option) was to introduce a "load' semantic to the API. This is similar to a put, except that here we force JBossCache to only acquire a read lock instead of the write lock. Thoughts? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3966053#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...