"manik.surtani(a)jboss.com" wrote : | +100. Hugely limiting in the way we have to support custom objects in Fqns right now. I understand why people don't want just Strings as Fqn elements, but we should restrict this to Strings + boxed primitives or something like that. | | Again, though, not something we can do now (2.1.0). Perhaps 3.0.0? | We should deprecate it in 2.1.0, but still allow it to work. It never worked like people expected anyway. Most importantly, we should change all of our code that does this sooner than later. 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. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4117157#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...