Details
-
Bug
-
Status: Patch Available
-
Major
-
Resolution: Unresolved
-
3.1.2
-
None
-
None
Description
Steps to reproduce:
1. `Drop database temp cascade`
2. Parallelly (after 1. but while 1. is running) fire a `create table temp.temp_table (a int, b int) clustered by (a) into 2 buckets stored as orc TBLPROPERTIES ('transactional'='true')`
3. Parallelly (after 2. but while 2. is running) fire a `insert overwrite table temp.temp_table values (1,2)`
note: The above could be easily reproduced by a unit test in testDbTxnManager.
Observation: Exclusive lock for Table in 3. is granted although exclusive lock for DB acquired in 1. is still acquired and shared read lock on DB for 2. is waiting.
Cause of issue: while acquiring a lock if we choose to ignore a conflict between the desired lock and one of the existing locks we immediately allow the desired lock to be acquired without checking against all the existing locks. The above-mentioned scenario was one such ignore conflict condition in 2. and 3. There could be other possible combinations where this may occur. Like for example when we request a lock with the same txn ids. Although hive guarantees that this scenario will not occur due to all lock requests related to a txn are asked at the same and failure of one guarantees failure of all, we in future will have to be extra careful with it.
Resolution: Whenever we ignore conflict we should keep looking against all the existing locks and only then allow the lock to be acquired.