hive-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eugene Koifman (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HIVE-15044) LockManager may be too coarse grained
Date Mon, 24 Oct 2016 20:23:58 GMT

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

Eugene Koifman updated HIVE-15044:
----------------------------------
    Description: 
Consider
{noformat}
create table target (a int, b int)
      partitioned by (p int, q int) clustered by (a) into 2  buckets 
      stored as orc TBLPROPERTIES ('transactional'='true')")
insert into target partition(p=1,q) values (1,2,3)
{noformat}

this insert will lock the whole table.  See 
{noformat}
DbTxnManager.acquireLocks()
switch (output.getType()) {
        case DUMMYPARTITION:   //
{noformat}

Insert operation runs with SHARED_READ lock but once HIVE-15032 is addressed this will be
an issue for Update/Delete/Merge which use a more restrictive SHARED_WRITE lock.

This can probably be achieved using "like /db/table/part/*" predicate making the LM operations
more expensive TxnHandler.checkLock()

  was:
Consider
{noformat}
create table target (a int, b int)
      partitioned by (p int, q int) clustered by (a) into 2  buckets 
      stored as orc TBLPROPERTIES ('transactional'='true')")
insert into target partition(p=1,q) values (1,2,3)
{noformat}

this insert will lock the whole table.  See 
{noformat}
DbTxnManager.acquireLocks()
switch (output.getType()) {
        case DUMMYPARTITION:   //
{noformat}

Insert operation runs with SHARED_READ lock but once HIVE-15032 is addressed this will be
an issue for Update/Delete/Merge which use a more restrictive SHARED_WRITE lock.

This can probably be achieved using "like /db/table/part/*" predicate making the LM operations
more expensive


> LockManager may be too coarse grained 
> --------------------------------------
>
>                 Key: HIVE-15044
>                 URL: https://issues.apache.org/jira/browse/HIVE-15044
>             Project: Hive
>          Issue Type: Improvement
>          Components: Transactions
>    Affects Versions: 1.0.0
>            Reporter: Eugene Koifman
>            Assignee: Eugene Koifman
>
> Consider
> {noformat}
> create table target (a int, b int)
>       partitioned by (p int, q int) clustered by (a) into 2  buckets 
>       stored as orc TBLPROPERTIES ('transactional'='true')")
> insert into target partition(p=1,q) values (1,2,3)
> {noformat}
> this insert will lock the whole table.  See 
> {noformat}
> DbTxnManager.acquireLocks()
> switch (output.getType()) {
>         case DUMMYPARTITION:   //
> {noformat}
> Insert operation runs with SHARED_READ lock but once HIVE-15032 is addressed this will
be an issue for Update/Delete/Merge which use a more restrictive SHARED_WRITE lock.
> This can probably be achieved using "like /db/table/part/*" predicate making the LM operations
more expensive TxnHandler.checkLock()



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message