[
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.
Federation engine should support JCR 1.0 (JSR-170) API
------------------------------------------------------
Key: DNA-46
URL:
http://jira.jboss.com/jira/browse/DNA-46
Project: DNA
Issue Type: Feature Request
Components: Federation, API
Reporter: Randall Hauch
Assigned To: Stefano Maestri
Priority: Critical
Fix For: 0.2
The federation engine should implement the JCR 1.0 API (JSR-170).
--
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