[dna-issues] [JBoss JIRA] Commented: (DNA-392) All sessions in a repository should share the same /jcr:system content

Randall Hauch (JIRA) jira-events at lists.jboss.org
Mon Jul 20 23:14:29 EDT 2009


    [ https://jira.jboss.org/jira/browse/DNA-392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476939#action_12476939 ] 

Randall Hauch commented on DNA-392:
-----------------------------------

The JCR implementation was changed so that the JcrRepository now uses an internal federated connector, with the "/jcr:system" branch being projected from an in-memory repository created and owned by the JcrRepository instance, and the remaining content being projected from the actual source being used by the JCR repository (which itself can be federated).  The internal NamespaceRegistry and RepositoryNodeTypeManager both use the internal in-memory source to make changes, and the "/jcr:system => /jcr:system" projection is then read-only (meaning the content under "/jcr:system" cannot be changed via the JcrSession or JcrWorkspace).

This design offers a couple of very nice features.  First of all, the federated connector was designed to handle this specific configuration, which it calls a "mirror-branch", since the main content is a mirror projection that is very cheap since it requires no path adjustments, and there is a single branch (the "jcr:system" branch) that also requires no path adjustments.

Secondly, this setup is managed by the JcrRepository instance and does not require any of the configured RepositorySource instances to be set up with a "jcr:system" branch.  However, this means that all JcrSession and JcrWorkspace instances created by the JcrRepository instance all share the exact same "jcr:system" content.

Third, the JcrSession and JcrWorkspace classes no longer do anything special with the "jcr:system" branch, making them much more lightweight.  In fact, none of the other code was changed (other than removing code that explicitly dealt with the pseudo "jcr:system" branch that appeared in each workspace).  These classes don't have to care where the "jcr:system" content comes from, since the content just is there.

Interestingly, there doesn't appear to be much of a change in the times required to run the build. On my machine, the change in times are well within the noise.  In fact, some builds with this change actually took less time to run all of the JCR unit tests than without this change.  I would guess that the extra time require to do the federation work is simply offset by the reduction in time required to create a session.

> All sessions in a repository should share the same /jcr:system content
> ----------------------------------------------------------------------
>
>                 Key: DNA-392
>                 URL: https://jira.jboss.org/jira/browse/DNA-392
>             Project: DNA
>          Issue Type: Task
>          Components: JCR
>    Affects Versions: 0.4
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Blocker
>             Fix For: 0.6
>
>
> Currently each JcrSession has its own copy of the /jcr:system content branch.  Technically this is incorrect, since all of the information in this branch is common to and shared by all sessions/workspaces in the repository.  One approach to making this work is to have a special workspace in the repository in which the content from the "/jcr:system" branch is placed, and have this workspace projected into each session.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


More information about the dna-issues mailing list