You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Marcel Reutegger (JIRA)" <ji...@apache.org> on 2007/08/31 14:32:37 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#action_12524065 ] 

Marcel Reutegger commented on JCR-890:
--------------------------------------

I hereby withdraw my proposal and state another one:

Move all synchronization in Jackrabbit that deals with concurrent read to the classes that implement the JCR API. In other words, make Jackrabbit entirely thread-safe for a client using the API. This includes all interfaces and not just the Repository.

Why did I change my mind? With a wrapper approach a client may (by mistake) still use Jackrabbit 'directly' and then use a single session instance from concurrent threads. So far we just say: well,  that's not supported, so it's your fault. If JCR is supposed to be infrastructure than an implementation should be robust and must not break just because some code does not behave as it should.

I even think the performance will be better compared to the current jackrabbit-core because we currently have many low level data structures that need to be synchronized. If we decide to synchronize on a coarser grained level like the API we can get rid of those low level synchronizations and as a result there will be less synchronized blocks that are entered.

> concurrent read-only access to a session
> ----------------------------------------
>
>                 Key: JCR-890
>                 URL: https://issues.apache.org/jira/browse/JCR-890
>             Project: Jackrabbit
>          Issue Type: Improvement
>          Components: core
>            Reporter: David Nuescheler
>            Assignee: Stefan Guggisberg
>
> 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.