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] Updated: (JCR-1820) Ensure queries are not blocked during large updates
Date Mon, 20 Oct 2008 13:21:44 GMT

     [ https://issues.apache.org/jira/browse/JCR-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Marcel Reutegger updated JCR-1820:

    Attachment: JCR-1820.patch

The proposed patch performs a check on the number of nodes that get added by the update and
prepares an index reader when the number is higher than the buffer size. This should be a
reasonable threshold because it will only trigger a writer flush when it is inevitable anyway.

> Ensure queries are not blocked during large updates
> ---------------------------------------------------
>                 Key: JCR-1820
>                 URL: https://issues.apache.org/jira/browse/JCR-1820
>             Project: Jackrabbit
>          Issue Type: Improvement
>          Components: jackrabbit-core
>            Reporter: Marcel Reutegger
>            Priority: Minor
>         Attachments: JCR-1820.patch
> The index currently guarantees that long running queries do not block updates. In addition
a query *may* run during an update, but there is not guarantee because it depends on the availability
of an index reader being available when the update starts. The index reader is invalidated
at the end of the update, which will force the creation of a new index reader when the next
query is executed.
> Consider the following scenario:
> 1) update index -> transaction id T1
> 2) potential index reader is invalidated
> 3) execute query -> creates index reader R1, which includes changes up to T1
> 4) update index -> transaction id T2
> 5) index reader R1 is invalidated
> 6) update index (large transaction) -> transaction id T3
> 7) while previous update is running execute query -> thread is blocked because no
reader is available
> The improvement should detect the large transaction and prepare an index reader for potential
queries during the update. That is, 6) should be split into:
> 6a) detect large transaction and prepare index reader R2, which includes changes up to
> 6b) update index -> transaction id T3
> While the update is running a query will use index reader R2.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message