[ 
https://issues.apache.org/jira/browse/HIVE-10242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14494775#comment-14494775
 ] 

Alan Gates commented on HIVE-10242:
-----------------------------------

bq.  The "default" in LockInfo constructor matches previous implementation. W/o 
the default, "switch" would just fall off the end and "type" and "state" will 
get default values, i.e. "null".
Agreed, but do we every want it to be null?  In both cases aren't the switch 
cases exhaustive?  If so, it's best to throw an exception if we find an 
unexpected case so that future developers quickly find their errors.

bq.   lockTypeComparator "static final" in LockInfoComparator...
I missed that this was static final.  Somehow I read it as a variable in the 
class.  What you have is fine.

So other than my nitpick on throwing an exception on the switch cases rather 
than returning null I'm +1 on this.



> ACID: insert overwrite prevents create table command
> ----------------------------------------------------
>
>                 Key: HIVE-10242
>                 URL: https://issues.apache.org/jira/browse/HIVE-10242
>             Project: Hive
>          Issue Type: Bug
>          Components: Transactions
>    Affects Versions: 1.0.0
>            Reporter: Eugene Koifman
>            Assignee: Eugene Koifman
>         Attachments: HIVE-10242.2.patch, HIVE-10242.3.patch, HIVE-10242.patch
>
>
> 1. insert overwirte table DB.T1 select ... from T2: this takes X lock on 
> DB.T1 and S lock on T2.
> X lock makes sense because we don't want anyone reading T1 while it's 
> overwritten. S lock on T2 prevents if from being dropped while the query is 
> in progress.
> 2. create table DB.T3: takes S lock on DB.
> This S lock gets blocked by X lock on T1. S lock prevents the DB from being 
> dropped while create table is executed.
> If the insert statement is long running, this blocks DDL ops on the same 
> database.  This is a usability issue.  
> There is no good reason why X lock on a table within a DB and S lock on DB 
> should be in conflict.  
> (this is different from a situation where X lock is on a partition and S lock 
> is on the table to which this partition belongs.  Here it makes sense.  
> Basically there is no SQL way to address all tables in a DB but you can 
> easily refer to all partitions of a table)



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

Reply via email to