[
https://issues.apache.org/jira/browse/OAK-5592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15857956#comment-15857956
]
Alex Parvulescu commented on OAK-5592:
--------------------------------------
I think this was discussed a bit in OAK-3380, so it's better to followup there
with your testcase and thoughts.
Also, this is mainly affecting DocumentMK, the SegmentTar storage already take
care of serializing the merge calls.
> 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
> Attachments: OAK-5592-test.patch
>
>
> 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)
