hive-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pravin Sinha (Jira)" <j...@apache.org>
Subject [jira] [Updated] (HIVE-24363) Current order of transactional event listeners is prone to deadlock in backend DB connections
Date Thu, 12 Nov 2020 11:01:00 GMT

     [ https://issues.apache.org/jira/browse/HIVE-24363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Pravin Sinha updated HIVE-24363:
--------------------------------
    Attachment: HIVE-24363.02.patch

> 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
>              Labels: pull-request-available
>         Attachments: HIVE-24363.01.patch, HIVE-24363.02.patch
>
>          Time Spent: 2h
>  Remaining Estimate: 0h
>
> 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)

Mime
View raw message