Please note that changing from Fqn to Fqn is going to 100% break the Hibernate 2nd Level Cache use case, requiring a major rewrite. I'm not at all certain the proper semantics can be maintained. We talked about this at JBW and I thought there might be a workable solution, but as I think about it more, I'm not seeing one yet. The workaround we've discussed involves hashing the entity PK and treating a cache node as a hash bucket, with the PK as a key in the node's attribute map. This leads to the potential to have lock conflicts between transactions that by chance use entities whose PKs resolve to the same hash bucket. It also breaks the current putForExternalRead implementation, which fails fast if the node exists. It also makes invalidation more coarse grained, since a write to one key in a bucket invalidates the entire bucket on all remote peers. We've bounced around the idea of not storing the entity as a value in the hash bucket node's attribute map, but rather a GUID string. Hibernate/JBC integration would first find the GUID, and then use that to construct a String-only Fqn where it would store the real entity. This would deal with the putForExternalRead problem. With a lot of jujitsu in the Hibernate/JBC integration it *perhaps* could get around most of the potential for lock conflicts. It would certainly be complicated and prone to race conditions as multiple peers attempt to cache entities. But, as I think about it, the GUID approach absolutely won't work with invalidation, as the PK/GUID key/value pair will never be available on any remote peer. Each node will therefore cache a given entity under a different Fqn, and an update of the entity on one node will fail to invalidate the other caches. Other thing we've discussed is asking the Hibernate guys to come up with some infrastructure to deterministically convert an entity PK into a unique string. But, 1) I don't think such magic exists, at least not for all types. For entities, we could add a requirement that all fields in the PK be primitive, which is not a major restriction, but is an obscure pain point. 2) For query caching, the equivalent to the entity PK is an object that encapsulates the query string and all parameters. Deterministically converting that object into a unique string is another more complex variant on the entity PK task. Lots of fun escaping stuff to distinguish our representation of things from random query content. Further, any entity field type used as a parameter than goes into the query needs to be "stringable", not just those the go into PKs. In practice, again not a major restriction, but an obscure pain point. 3) Perhaps most significantly, I don't see providing such an API as being a high priority for the Hibernate team. Bottom line, please recognize that making whatever JBC release incorporates this switch usable for Hibernate will be a pain. At minimum it will take time and resources, and the effort will compete for resources with whatever other things are going on. And thus may take longer. At worst, it will introduce a problem that can't be solved effectively. Either way, until the new integration is done, that JBC release will not be usable by EJB3 or JBoss AS. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4135113#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...