What I am saying is that there is two usage patterns which force Hibernate to do puts into the cache. But to JBossCache, a put is a put is a put and as such always receives a write lock; it does not distinguish the purpose or the context of the put.
(1) Hibernate loads data from the database and perfoms a put into the cache. This is the one discussed before. This is logically just a read. We are not putting a change of system state into the cache. Thus this should be a read lock to minimize contention. (2) User, via Hibernate, modifies some data requiring Hibernate to do a put into the cache to store the new state. This should be write locked. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3966232#3966232 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3966232 _______________________________________________ jboss-user mailing list [email protected] https://lists.jboss.org/mailman/listinfo/jboss-user
