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