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] Commented: (JCR-890) concurrent read-only access to a session
Date Tue, 18 May 2010 12:32:45 GMT

    [ 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.


Mime
View raw message