jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcel Reutegger (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-890) concurrent read-only access to a session
Date Fri, 31 Aug 2007 12:32:37 GMT

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

View raw message