"jason.greene(a)jboss.com" wrote : | This is an example of how it could possibly work with entity caching: | | | /entities/[TYPE]/[HASHCODE] | | KEY1 -> UUID1 | | KEY2 -> UUID2 | | KEY3 -> UUID3 | | /entities/[TYPE]/[HASHCODE]/[UUID1] | | [FIELD_NAME] -> [FIELD_VALUE] | | ... | | /entities/[TYPE]/[HASHCODE]/[UUID2] | | [FIELD_NAME] -> [FIELD_VALUE] | | ... | | /entities/[TYPE]/[HASHCODE]/[UUID3] | | [FIELD_NAME] -> [FIELD_VALUE] | | ... | | | | So a given entity requires 2 node lookups, no matter the number of collisions. There will, of course, be contention on the hashcode, but this is expected. With Hibernate entity caching there's no second node, as the value is a single Object[] representing the entity fields. Some problems with this: 1) Can lead to deadlocks: node A updates entity 1, node B updates entity 2; they resolve to the same hashcode. Even with your UUID approach you can have that problem if A and B are inserting. 2) If you don't have two nodes per entity, putForExternalRead no longer works properly, since it uses the presence of the node to decide to quickly abort. That may be trivial to solve; I don't know. 3) With the 2 node solution, where does the UUID come from? These aren't sessions; each node in the cluster would need to come up with the same UUID for a given key. Sorry, still jet-lagged; I can only raise problems today; no solutions :( View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4117717#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...