You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hive.apache.org by "Eugene Koifman (JIRA)" <ji...@apache.org> on 2018/02/09 22:57:00 UTC

[jira] [Updated] (HIVE-15077) Acid LockManager is unfair

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

Eugene Koifman updated HIVE-15077:
----------------------------------
    Description: 
HIVE-10242 made the acid LM unfair.

In TxnHandler.checkLock(), suppose we are trying to acquire SR5  (the number is extLockId).  

Then 
LockInfo[] locks = lockSet.toArray(new LockInfo[lockSet.size()]);

may look like this (all explicitly listed locks are in Waiting state)

{...., SR5 SW3 X4}

So the algorithm will find SR5 in the list and start looking backwards (to the left).
According to IDs, SR5 should wait for X4 to be granted but X4 won't even be examined and so SR5 may be granted.

Theoretically, this could cause starvation.

The query that generates the list already has
query.append(" and hl_lock_ext_id <= ").append(extLockId);

but it should use "<" rather than "<=" to exclude the locks being checked from "locks" list which will make the algorithm look at all locks "in front" of a given lock.

  was:
HIVE-10242 made the acid LM unfair.

In TxnHandler.checkLock(), suppose we are trying to acquire SR5  (the number is extLockId).  

Then 
LockInfo[] locks = lockSet.toArray(new LockInfo[lockSet.size()]);

may look like this (all explicitly listed locks are in Waiting state)

{...., SR5 SW3 X4}

So the algorithm will find SR5 in the list and start looking backwards.
According to IDs, SR5 should wait for X4 to be granted but X4 won't even be examined and so SR5 may be granted.

Theoretically, this could cause starvation.

The query that generates the list already has
query.append(" and hl_lock_ext_id <= ").append(extLockId);

but it should use "<" rather than "<=" to exclude the locks being checked from "locks" list which will make the algorithm look at all locks "in front" of a given lock.


> Acid LockManager is unfair
> --------------------------
>
>                 Key: HIVE-15077
>                 URL: https://issues.apache.org/jira/browse/HIVE-15077
>             Project: Hive
>          Issue Type: Bug
>          Components: Transactions
>            Reporter: Eugene Koifman
>            Assignee: Eugene Koifman
>            Priority: Blocker
>
> HIVE-10242 made the acid LM unfair.
> In TxnHandler.checkLock(), suppose we are trying to acquire SR5  (the number is extLockId).  
> Then 
> LockInfo[] locks = lockSet.toArray(new LockInfo[lockSet.size()]);
> may look like this (all explicitly listed locks are in Waiting state)
> {...., SR5 SW3 X4}
> So the algorithm will find SR5 in the list and start looking backwards (to the left).
> According to IDs, SR5 should wait for X4 to be granted but X4 won't even be examined and so SR5 may be granted.
> Theoretically, this could cause starvation.
> The query that generates the list already has
> query.append(" and hl_lock_ext_id <= ").append(extLockId);
> but it should use "<" rather than "<=" to exclude the locks being checked from "locks" list which will make the algorithm look at all locks "in front" of a given lock.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)