You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hive.apache.org by "Pravin Sinha (Jira)" <ji...@apache.org> on 2020/11/10 04:38:00 UTC
[jira] [Updated] (HIVE-24363) Current order of transactional event
listeners is prone to deadlock in backend DB connections
[ https://issues.apache.org/jira/browse/HIVE-24363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Pravin Sinha updated HIVE-24363:
--------------------------------
Description:
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.
was:
Currently the AcidEventListener is added to the end of list transactional event listeners. When DbNotificationListener is configured in 'hive.metastore.transactional.event.listeners'. The 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 a jvm lock.
> 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)