The problem we have is that sometimes, probably when an executor is unexpectedly interrupted, the shared lock is not released at the end of execution. That results in a lock without owner, so the lock must be manually unlocked if we want to update the content of the database. I want to know why that happens. Is it a documented bug? Can we reproduce it? Is there a known fix/workaround? If we disable the concurrency we would get a situation where every query on a database claims an exclusive lock (which means only one query can be running on the database at once). That is not the wanted behavior. `show locks se_core.avaya_echi_tele2 extended` results in ``` tab_name mode 1 se_core@avaya_echi_tele2 SHARED 2 LOCK_QUERYID:hive_20170411120707_e99059e2-bfcb-40e8-b343-2d2551f9dd67 NULL 3 LOCK_TIME:1491905245078 NULL 4 LOCK_MODE:IMPLICIT NULL 5 LOCK_QUERYSTRING:SELECT * FROM se_core.avaya_echi_tele2 limit 3 NULL``` ... View more