[
https://issues.apache.org/jira/browse/HIVE-8711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14197323#comment-14197323
]
Eugene Koifman commented on HIVE-8711:
--------------------------------------
1. TxnHandler.detectDeadlock() - I think it makes sense to implement it like
getDbTime() so that checks only what is expected for a given DB type. For
example, if Oracle throws 40001, current code will assume it's a deadlock.
2. DeadLockCreator - it seems that it can easily guarantee deadlock by calling
updateTxns(conn1), updateLocks(conn2), updateLocks(conn1). It could then be
enabled permanently.
3. Nit: why are constants in TxnHandler, such as LOCK_ACQUIRED 'protected'
They are only used in test code which is the same package as TxnHandler.
4. This not related to this bug, but MetaStoreThread.BooleanPointer() has
multiple threads reading/writing a boolean variable which is not volatile or
AtomicBoolean... this looks like a recipe for trouble
> DB deadlocks not handled in TxnHandler for Postgres, Oracle, and SQLServer
> --------------------------------------------------------------------------
>
> Key: HIVE-8711
> URL: https://issues.apache.org/jira/browse/HIVE-8711
> Project: Hive
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 0.14.0
> Reporter: Alan Gates
> Assignee: Alan Gates
> Priority: Critical
> Fix For: 0.14.0
>
> Attachments: HIVE-8711.patch
>
>
> TxnHandler.detectDeadlock has code to catch deadlocks in MySQL and Derby.
> But it does not detect a deadlock for Postgres, Oracle, or SQLServer
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
