[
https://issues.apache.org/jira/browse/OMID-107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16592551#comment-16592551
]
Yonatan Gottesman commented on OMID-107:
----------------------------------------
Hi [James
Taylor|https://issues.apache.org/jira/secure/ViewProfile.jspa?name=jamestaylor],
ok my bad there is no loop
!https://ci6.googleusercontent.com/proxy/FTB51wOrZVKbRl_zQf7YSQjdn8mW5V_D-M0O-pfrz9B_k6Soh5KvrVxDabFVqZ_NtkzYKpTYv9gVPrftNTMhAcj76j_GTnuWFkJp6dBYBqDYWrtANA=s0-d-e1-ft#https://issues.apache.org/jira/images/icons/emoticons/smile.png|width=16,height=16,align=absmiddle!
.
The test onced passed and now doesnt because in your ttable function
addMutaion(List<Put>) you just call addMutations(puts); but you forgot to go
through the whole ttable.put mechanizm (add timestamps...) so if you change the
function to:
{code:java}
public void put(Transaction transaction, List<Put> puts) throws IOException {
for (Put put: puts) {
put(transaction, put);
}
}
{code}
The test will pass.
About why the test works how it works:
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:
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);
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.
> 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)
