jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "angela (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-890) concurrent read-only access to a session
Date Tue, 18 May 2010 10:37:44 GMT

    [ https://issues.apache.org/jira/browse/JCR-890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12868599#action_12868599

angela commented on JCR-890:

my comments from a quick first glance at the patches:

why is the package called 'session'? from your explanation on the dev list ("[...] to move
most of the session-related classes from o.a.j.core to 
a new o.a.j.core.session package [...]") i would have expected that this is related to either
JCR API implementations in close relationship to 
the Session or modifications on the Session level (aka transient modifications).
but now the patch moves classes that i wouldn't have expected to be affected based your explanation:
BatchedItemOperations (purely workspace operations on the  item state level), ItemData and
subclasses (really internal stuff) just to mention 2 of them. what was the design behind those

second i have strong concern regarding changing the visibility of so many classes and methods
that i consider to be repository internals.
making them all public feels really wrong to me.... what exactly do you mean by "My plan is
to refactor these cases so that we don't expose more of the Jackrabbit internals to client
code."? if you plan major refactoring of other core classes not affected by the move, why
not addressing this first before
moving classes that from my point of view don't belong to the target package?

-1 for the current patch.

> 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, session-class-move.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