[
https://issues.apache.org/jira/browse/JCR-890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12868623#action_12868623
]
Jukka Zitting commented on JCR-890:
-----------------------------------
Thanks for the review!
> why is the package called 'session'?
Perhaps some other term than "session" would be clearer. The way I see the
current Jackrabbit architecture (as muddy as it at times is), there are
basically two main parts:
1) "repository" part that consists of the global persisted state stored in
persistence managers, node type registry, etc. This state is seen and shared by
all clients that access the repository.
2) "session" part that consist of the transient changes that have not yet been
persisted. This part is private to each client. Note that I also consider
things like immediately persisted workspace operations (imports, copies and
moves, etc.) as part of the "session" layer up to the point when the relevant
ChangeLog gets persisted. Thus I count also classes like BatchedItemOperations
as part of this architectural layer.
Would "global" and "local" be better terms? Note that I'd rather avoid labels
like "persisted" and "transient" to prevent confusion with things like JCR-2051
(and since "transient" is a reserved word in Java).
Basically, when I talk about "session-related classes" above, I mean code
related to point 2 above.
> visibility
I was planning to move these classes first so I'd have a better picture of
these package-private dependencies (as seen in
session-class-move-norename.patch) before refactoring them away. Note that in
most cases I expect these changes to be minor refactorings, like replacing a
call to RepositoryImpl.getSomething() with an injected dependency. But yes, I
can take care of this also before other changes.
> 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.
