phoenix-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lars Hofhansl (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (PHOENIX-5233) Read-your-own writes causes incorrect visibility with transactional tables (with Omid).
Date Sat, 13 Apr 2019 18:10:00 GMT

    [ https://issues.apache.org/jira/browse/PHOENIX-5233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16817031#comment-16817031
] 

Lars Hofhansl commented on PHOENIX-5233:
----------------------------------------

Hi [~yonigo], the data isn't seen because HBase has its own internal MVCC snapshotting. A
scan in HBase will only see data as if its readpoint. BUT... If the a region is moved or split
any scanners there were open in that region are restarted with a *new* readpoint. So in that
case some data inserted after the original scanner started will be seen.

The HBase contract is: Each is guaranteed to see all data that existed before the scanner
started. The scanner may see some data inserted after the scanner started.

OK. So it seems you agree that we should always checkpoint. Now, is this something to fix
in Phoenix (because it is specific to UPSERT/SELECT) or something that we should fix in Omid
(because it violates snapshot semantics within a transaction)?

The little Phoenix change in my previous comment does fix the issue.

> Read-your-own writes causes incorrect visibility with transactional tables (with Omid).
> ---------------------------------------------------------------------------------------
>
>                 Key: PHOENIX-5233
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-5233
>             Project: Phoenix
>          Issue Type: Bug
>    Affects Versions: 4.14.1
>            Reporter: Lars Hofhansl
>            Assignee: Yonatan Gottesman
>            Priority: Major
>         Attachments: 5233-tests.txt, 5233-v4.txt, 5233-v5.txt, 5233-v6.txt
>
>
> (copied from my last comment on PHOENIX-5090)
> Steps to reproduce (with Omid):
>  # {{!autocommit off}}
>  # {{create table test (pk1 integer not null, pk2 integer not null, pk3 integer not null,
v1 float, v2 float, v3 integer CONSTRAINT pk PRIMARY KEY (pk1, pk2, pk3)) DISABLE_WAL=true,
TRANSACTIONAL=true;}}
>  # {{upsert into test values(rand()*10000000, rand()*10000000, rand()*10000000, rand(),
rand(), rand()*1000000);}}
>  # {{upsert into test select rand()*10000000, rand()*10000000, rand()*10000000, rand(),
rand(), rand()*1000000 from test;}}
>  # {{select count\(*) from test; – this will cause uncommitted data to sent to the
server.}}
>  # Goto #4 a few time (until you inserted 131072 rows)
>  # {{!commit}}
> In a separate sqlline session just repeat after the commit was issued in the other session.
> * {{select count\(*) from test;}}
> You'll see that number will change until it finally settles.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message