[
https://issues.apache.org/jira/browse/HIVE-12686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eugene Koifman updated HIVE-12686:
----------------------------------
Description:
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.
was:
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.
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.
> 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)
