jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting (JIRA)" <j...@apache.org>
Subject [jira] Updated: (JCR-890) concurrent read-only access to a session
Date Mon, 17 May 2010 15:54:44 GMT

     [ https://issues.apache.org/jira/browse/JCR-890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Jukka Zitting updated JCR-890:

    Attachment: session-class-move-norename.patch

As a first step to implementing this, I'd like to make the following moves of session-related
classes form o.a.j.core to a new o.a.j.core.session package. As discussed on dev@, the rationale
for this change is to be able to better manage the code paths to and from the internal state
of each session.

    cd jackrabbit-trunk/src/main/java/org/apache/jackrabbit/core
    svn mkdir session
    svn move AbstractNodeData.java session
    svn move BatchedItemOperations.java session
    svn move ItemData.java session
    svn move ItemImpl.java session
    svn move ItemLifeCycleListener.java session
    svn move ItemManager.java session
    svn move ItemValidator.java session
    svn move LazyItemIterator.java session
    svn move NodeData.java session
    svn move NodeDataRef.java session
    svn move NodeImpl.java session
    svn move PropertyData.java session
    svn move PropertyImpl.java session
    svn move ProtectedItemModifier.java session
    svn move SessionImpl.java session
    svn move SessionListener.java session
    svn move SystemSession.java session
    svn move VersionManagerImpl.java session
    svn move WorkspaceImpl.java session
    svn move XASessionImpl.java session
    svn move XAWorkspace.java session

The attached patch (session-class-move.patch) contains all the import statement changes and
other minor refactorings required to make the trunk compile and pass all tests after the above

Note that the patch includes dummy child classes in org.apache.jackrabbit.core for the JCR
implementation classes ItemImpl, NodeImpl, PropertyImpl, SessionImpl, VersionManagerImpl and
WorkspaceImpl. These classes simply inherit the similarly named classes that were moved to
o.a.j.core.session. The purpose of these classes is to maintain compatibility with client
code that casts JCR objects to Jackrabbit implementation classes. Later on it may be a good
idea to turn these classes into facades that access the underlying functionality in o.a.j.core.session
after taking care of trivial operations like name/path parsing, etc.

This step is a purely structural refactoring, it does not introduce any functional changes
in the code. All code outside o.a.j.core and o.a.j.core.session can be updated to reflect
these changes simply by updating the relevant import statements. To make reviewing the patch
easier, I've attached also a version without all the trivial package renames (session-class-move-rename.patch).
Note that the new package boundary required changes to the visibility of a number of methods
and classes. My plan is to refactor these cases so that we don't expose more of the Jackrabbit
internals to client code.

> concurrent read-only access to a session
> ----------------------------------------
>                 Key: JCR-890
>                 URL: https://issues.apache.org/jira/browse/JCR-890
>             Project: Jackrabbit Content Repository
>          Issue Type: Improvement
>          Components: jackrabbit-core
>            Reporter: David Nuescheler
>            Assignee: Jukka Zitting
>             Fix For: 2.2.0
>         Attachments: session-class-move-norename.patch
> Even though the JCR specification does not make a statement about Sessions shared across
a number of threads I think it would be great for many applications if we could state that
sharing a read-only session is supported by Jackrabbit.
> On many occasions in the mailing lists we stated that there should not be an issue with
sharing a read-only session, however I think it has never been thoroughly tested or even specified
as a "design goal".
> If we can come to an agreement that this is desirable I think it would be great to start
including testcases to validate that behaviour and update the documentation respectively.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message