[jira] [Comment Edited] (HIVE-24363) Current order of transactional event listeners is prone to deadlock in backend DB connections

["Pravin Sinha (Jira)" <ji...@apache.org>]

    [ 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)