You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hive.apache.org by "Marton Bod (Jira)" <ji...@apache.org> on 2020/03/19 10:49:00 UTC

[jira] [Work started] (HIVE-23052) Optimize lock enqueueing in TxnHandler

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

Work on HIVE-23052 started by Marton Bod.
-----------------------------------------
> Optimize lock enqueueing in TxnHandler
> --------------------------------------
>
>                 Key: HIVE-23052
>                 URL: https://issues.apache.org/jira/browse/HIVE-23052
>             Project: Hive
>          Issue Type: Improvement
>            Reporter: Marton Bod
>            Assignee: Marton Bod
>            Priority: Major
>
> TxnHandler::enqueueLockWithRetry uses select for update (S4U) to retrieve the next lock id from the metastore. This locks the NEXT_LOCK_ID table for concurrent lock requests until the transaction has been committed.
> Since this creates contention, we should reduce the scope of this S4U, thereby locking the table for only as long as necessary. Currently, within the same txn, after the initial S4U, we also insert the transaction components (TXN_COMPONENTS table) before committing, even though they are independent and do not make use of the lock id. So factoring out these txn_component inserts should decrease the time the next_lock_id table is locked and thus increase concurrency.
>  



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