[
https://issues.apache.org/jira/browse/OMID-107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16591611#comment-16591611
]
Yonatan Gottesman commented on OMID-107:
----------------------------------------
Hi [~jamestaylor], ok my bad there is no loop :).
About the test, I think the writer expected the wrong behaviour of scan with
filters (the behaviour we fixed with coprocessors in omid-102).
look at this scan with filter:
{code:java}
Filter f = new SingleColumnValueFilter(famName, colName,
CompareFilter.CompareOp.EQUAL, Bytes.toBytes(20));
Scan checkFor20 = new Scan();
checkFor20.setFilter(f);
ResultScanner checkFor20Scanner = txTable.getScanner(tx1, checkFor20);
{code}
The filter f will run before omid filtering, and see the value 18 in row2 even
though the value is not in the scanners snapshot, so the filter looking or
op.EQUAL 20 won't filter out the row and the row will be returned to omid
filtering that will look for the key in our snapshot with the old value 20.
Now tx1 tries to delete row2 and of course will fail because write-write
conflict with tx2.
If they had the omid-102 working, and ran the test with the coprocessors, then
the filter f would run after omid filtering and see value 20 and emitt the
whole row. then the delete wont take place at all and the snapshot won't fail.
I suggest we remove this test and add a log warning every time a user uses a
filter in a get/scan op but runs without coprocessors.
Does this make sense?
> Replace HTableInterface with Table
> ----------------------------------
>
> Key: OMID-107
> URL: https://issues.apache.org/jira/browse/OMID-107
> Project: Apache Omid
> Issue Type: Sub-task
> Reporter: James Taylor
> Priority: Major
> Attachments: OMID-107.patch
>
>
> In HBase 2.0, the HTableInterface has been replaced with the Table interface.
> Thus, in Omid, this same replacement should take place. This will mostly be
> isolated to having TTable implement Table instead of HTableInterface. This
> will be required to check-in Omid support in Phoenix, since Phoenix 5.x is
> based on HBase 2.0.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
