Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
1.3.0
-
None
-
None
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.
Attachments
Issue Links
- depends upon
-
HIVE-12832 RDBMS schema changes for HIVE-11388
- Closed
-
HIVE-12366 Refactor Heartbeater logic for transaction
- Closed
- is related to
-
HIVE-16564 StreamingAPI is locking too much?
- Open
- relates to
-
HIVE-12421 Streaming API add TransactionBatch.beginNextTransaction(long timeout)
- Open