jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Wellenzohn (JIRA)" <j...@apache.org>
Subject [jira] [Created] (OAK-5592) Write Skew in the Property Index
Date Mon, 06 Feb 2017 13:10:41 GMT
Kevin Wellenzohn created OAK-5592:
-------------------------------------

             Summary: Write Skew in the Property Index
                 Key: OAK-5592
                 URL: https://issues.apache.org/jira/browse/OAK-5592
             Project: Jackrabbit Oak
          Issue Type: Bug
            Reporter: Kevin Wellenzohn
            Priority: Minor


Under certain circumstances the property index (using the {{ContentMirrorStoreStrategy}})
may not prune all nodes that could be pruned.

Assume two nodes {{child1}} and {{child2}} having property {{foo}} set to {{bar}} exist under
a common parent node. Moreover, a property index on {{foo}} exists. The tree would look like
this:

{noformat}
  - parent
    - child1[foo=bar]
    - child2[foo=bar]
  - oak:index
    - foo
      - :index
        - bar
          - parent
            - child1[match=true]
            - child2[match=true]
{noformat}

Assume two concurrent transactions {{T1}} and {{T2}} remove property {{foo}} from {{child1}}
and {{child2}}, respectively. Since the transactions do not see the effects of one another,
they do not prune node {{/oak:index/foo/:index/bar/parent}}. The reason is that even after
pruning their respective child node, there is still a second child node left. Therefore, after
{{T1}} and {{T2}} execute, the tree looks like this

{noformat}
  - parent
    - child1
    - child2
  - oak:index
    - foo
      - :index
        - bar
          - parent
{noformat}

In a serializable exeuction of {{T1}} and {{T2}}, the tree should look like this:

{noformat}
  - parent
    - child1
    - child2
  - oak:index
    - foo
      - :index
{noformat}

This "bug" does not affect query correctness, but it might impact query performance if it
happens frequently, since nodes are traversed that not need be traversed otherwise.  I'm not
even sure if this is a bug; I see this as an instantiation of the Write Skew problem \[1,2\]
inherent to MVCC and as such it is probably "expected behavior".

\[1\] http://jackrabbit.apache.org/oak/docs/architecture/transactional-model.html
\[2\] https://issues.apache.org/jira/browse/OAK-26




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Mime
View raw message