You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "angela (JIRA)" <ji...@apache.org> on 2010/05/18 12:37:44 UTC

[jira] Commented: (JCR-890) concurrent read-only access to a session

    [ 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 moves?

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.