hive-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eugene Koifman (JIRA)" <>
Subject [jira] [Commented] (HIVE-18570) ACID IOW implemented using base may delete too much data
Date Tue, 01 May 2018 17:07:00 GMT


Eugene Koifman commented on HIVE-18570:

longer term we should should support snapshot isolation with optimistic concurrency (as much
as possible) and read committed with pessimistic lock based concurrency.  Optimistic conflict
detection currently only tracks update/delete conflicts and making it track inserts as well
is a bigger change than I want to do for 3.0

> ACID IOW implemented using base may delete too much data
> --------------------------------------------------------
>                 Key: HIVE-18570
>                 URL:
>             Project: Hive
>          Issue Type: Bug
>          Components: Transactions
>            Reporter: Sergey Shelukhin
>            Assignee: Eugene Koifman
>            Priority: Blocker
>         Attachments: HIVE-18570.01-branch-3.patch, HIVE-18570.01.patch
> Suppose we have a table with delta_0 insert data.
> Txn 1 starts an insert into delta_1.
> Txn 2 starts an IOW into base_2.
> Txn 2 commits.
> Txn 1 commits after txn 2 but its results would be invisible.
> Txn 2 deletes rows committed by txn 1 that according to standard ACID semantics it could
have never observed and affected; this sequence of events is only possible under read-uncommitted
isolation level (so, 2 deletes rows written by 1 before 1 commits them). 
> This is if we look at IOW as transactional delete+insert. Otherwise we are just saying
IOW performs "semi"-transactional delete.
> If 1 ran an update on rows instead of an insert, and 2 still ran an IOW/delete, row lock
conflict (or equivalent) should cause one of them to fail.

This message was sent by Atlassian JIRA

View raw message