[ http://jira.jboss.com/jira/browse/DNA-46?page=comments#action_12417391 ] Randall Hauch commented on DNA-46: ---------------------------------- There are a couple of goals we want to keep in mind regarding our JCR implementation. One is to make it easy to manage the number and set of Node instances in memory. For example, if a node has a Java reference to its children and parent, then any reference to a node basically causes the whole graph to be kept in memory. We could instead decouple the instances by eliminating inter-node references (or by using weak/soft references) and use internal IDs (e.g., UUIDs) for node references, allowing us much more control about which nodes to maintain in memory. Another goal would be to not create duplicate Node implementation instances. For example, if the client gets the Node for some path P and assigns it to a variable 'x', and then again gets the Node for some path X and assigns it to another variable 'y', those objects should not only be equal but also should be the same instance. In other words, the client should be able to check 'x == y'. Third, remember that the federation engine will have it's own cache of integrated/merged node information. So we don't want to duplicate a complex cache in the Sessions. Finally, we need to support the proper level of concurrency from the very beginning. According to the JCR specification (Section 7.5 of JSR-170-1.0.1.pdf, or section 5.8 of the draft JSR-183 spec), the Repository implementation must be thread-safe, but the other interfaces do not need to be. I believe that all these can be accomplished by maintaining a Map<UUID,SoftReference<NodeImpl>>, where the key is the UUID of the integrated node (maintained by the federation engine, even if the sources have different UUIDs or no UUIDs for the same node) and the value is a soft reference to the node implementation. With soft references, entries can be reclaimed automatically by the VM as hard references no longer exist and as GC is required. (Weak references get reclaimed immediately when hard references no longer exist.) Depending upon who owns this map (Repository or Session), this could also be a ConcurrentMap implementation, which achieves all of the benefits of concurrency without using locking. In this approach, the NodeImpl would hold only the UUIDs of its children, allowing nodes to be moved around and names to be changed very efficiently. The only downside is that when nodes are retrieved by path, the nodes representing the path all have to be materialized. If the cache works well, that shouldn't be a problem and in fact may be a benefit. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira