[
https://issues.apache.org/jira/browse/HIVE-24363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17228969#comment-17228969
]
Pravin Sinha edited comment on HIVE-24363 at 11/10/20, 4:47 AM:
----------------------------------------------------------------
One other problem is that thread processing the listeners
\{"DbNotificationListener" , "AcidEventListener"} uses two different db
connections, and hence even though it is a deadlock condition, the backend db
cannot detect and terminate it immediately (Even when deadlock detection is
ON). The deadlock will be broken only after lock aquisition wait timeout
expires (say, in mySQL case 'innodb_lock_wait_timeout' value). If this config
is set to a higher value, we might end up having larger impact.
was (Author: pkumarsinha):
One other problem is that thread processing the listeners
\{"DbNotificationListener" , "AcidEventListener"} uses two different db
connections, and hence even though it is a deadlock condition, the backend db
cannot detect terminate it immediately (Even when deadlock detection is ON).
The deadlock will be broken only after lock aquisition wait timeout expires
(say, in mySQL case 'innodb_lock_wait_timeout' value). If this config is set to
a higher value, we might end up having larger impact.
> Current order of transactional event listeners is prone to deadlock in
> backend DB connections
> ---------------------------------------------------------------------------------------------
>
> Key: HIVE-24363
> URL: https://issues.apache.org/jira/browse/HIVE-24363
> Project: Hive
> Issue Type: Bug
> Reporter: Pravin Sinha
> Assignee: Pravin Sinha
> Priority: Major
>
> Currently the AcidEventListener is added to the end of list of transactional
> event listeners. When DbNotificationListener is configured as
> 'hive.metastore.transactional.event.listeners'. The final list will be formed
> as :
> {"DbNotificationListener" , "AcidEventListener"}
> This will result in backend DB lock acquisition in this order:
> {code:java}
> lock(a) {
> // perform some op on a
> lock(b) {
> // perform some op on b
> }
> }
> {code}
> On the other hand, there are some HMS API say for example commit_txn(), which
> calls the TxnHandler method directly, followed by DbNotificationListener
> processing. Which will result in the lock acquisition in reverse order:
> {code:java}
> lock(b) {
> // perform some op on b
> lock(a) {
> // perform some op on a
> }
> }
> {code}
> Note: 'a' and 'b' above are backend DB lock and not jvm locks.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
