[jira] [Updated] (HIVE-19369) Locks: Add new lock implementations for always zero-wait readers

["Denys Kuzmenko (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/HIVE-19369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Denys Kuzmenko updated HIVE-19369:
----------------------------------
    Attachment: HIVE-19369.1.patch

> Locks: Add new lock implementations for always zero-wait readers
> ----------------------------------------------------------------
>
>                 Key: HIVE-19369
>                 URL: https://issues.apache.org/jira/browse/HIVE-19369
>             Project: Hive
>          Issue Type: Improvement
>          Components: Transactions
>            Reporter: Gopal Vijayaraghavan
>            Assignee: Denys Kuzmenko
>            Priority: Major
>         Attachments: HIVE-19369.1.patch
>
>
> Hive Locking with Micro-managed and full-ACID tables needs a better locking implementation which allows for no-wait readers always.
> EXCL_DROP
> EXCL_WRITE
> SHARED_WRITE
> SHARED_READ
> Short write-up
> EXCL_DROP is a "drop partition" or "drop table" and waits for all others to exit
> EXCL_WRITE excludes all writes and will wait for all existing SHARED_WRITE to exit.
> SHARED_WRITE allows all SHARED_WRITES to go through, but will wait for an EXCL_WRITE & EXCL_DROP (waiting so that you can do drop + insert in different threads).
> SHARED_READ does not wait for any lock - it fails fast for a pending EXCL_DROP, because even if there is an EXCL_WRITE or SHARED_WRITE pending, there's no semantic reason to wait for them to succeed before going ahead with a SHARED_WRITE.
> a select * => SHARED_READ
> an insert into => SHARED_WRITE
> an insert overwrite or MERGE => EXCL_WRITE
> a drop table => EXCL_DROP
> TODO:
> The fate of the compactor needs to be added to this before it is a complete description.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)