You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hive.apache.org by "Jesus Camacho Rodriguez (JIRA)" <ji...@apache.org> on 2016/05/25 16:26:13 UTC
[jira] [Commented] (HIVE-12686)
TxnHandler.checkLock(CheckLockRequest) perf improvements
[ https://issues.apache.org/jira/browse/HIVE-12686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15300355#comment-15300355 ]
Jesus Camacho Rodriguez commented on HIVE-12686:
------------------------------------------------
Removing 2.1.0 target. Please feel free to commit to branch-2.1 anyway and fix for 2.1.0 if this happens before the release.
> TxnHandler.checkLock(CheckLockRequest) perf improvements
> --------------------------------------------------------
>
> Key: HIVE-12686
> URL: https://issues.apache.org/jira/browse/HIVE-12686
> Project: Hive
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 1.3.0
> Reporter: Eugene Koifman
> Assignee: Eugene Koifman
>
> CheckLockRequest should include txnid since the caller should always know this (if there is a txn).
> This would make getTxnIdFromLockId() call unnecessary.
> checkLock() is usually called much more often (especially at the beginning of exponential back off sequence), thus a lot of these heartbeats are overkill. Could also include a time (in ms) since last checkLock() was called and use that to decide to heartbeat or not.
> In fact, if we made heartbeat in DbTxnManager start right after locks in "W" state are inserted, heartbeat in checkLock() would not be needed at all.
> This would be the best solution but need to make sure that heartbeating is started appropriately in Streaming API - currently it does not. It requires the client to start heartbeating.
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)