hadoop-hive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Sichi (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HIVE-1293) Concurreny Model for Hive
Date Thu, 12 Aug 2010 23:55:21 GMT

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

John Sichi commented on HIVE-1293:
----------------------------------

After seeing some other issues, had a chat with Namit about semantics; here's what we worked
out.

* Normally, locks should only be held for duration of statement execution.
* However, LOCK TABLE should take a global lock (not tied to any particular session or statement).
* UNLOCK TABLE should remove both kinds of lock (statement-level and global).  Likewise, SHOW
LOCKS shows all.
* For fetching results, we'll need a parameter to control whether a dirty read is possible.
 Normally, this is not an issue since we're fetching from saved temp results, but when using
select * from t to fetch directly from the original table, this behavior makes a difference.
 To prevent dirty reads, we'll need the statement-level lock to span the duration of the fetch.

To avoid leaks, we need to make sure that once we create a ZooKeeper client, we always close
it.


> Concurreny Model for Hive
> -------------------------
>
>                 Key: HIVE-1293
>                 URL: https://issues.apache.org/jira/browse/HIVE-1293
>             Project: Hadoop Hive
>          Issue Type: New Feature
>          Components: Query Processor
>            Reporter: Namit Jain
>            Assignee: Namit Jain
>             Fix For: 0.7.0
>
>         Attachments: hive.1293.1.patch, hive.1293.2.patch, hive.1293.3.patch, hive.1293.4.patch,
hive.1293.5.patch, hive_leases.txt
>
>
> Concurrency model for Hive:
> Currently, hive does not provide a good concurrency model. The only guanrantee provided
in case of concurrent readers and writers is that
> reader will not see partial data from the old version (before the write) and partial
data from the new version (after the write).
> This has come across as a big problem, specially for background processes performing
maintenance operations.
> The following possible solutions come to mind.
> 1. Locks: Acquire read/write locks - they can be acquired at the beginning of the query
or the write locks can be delayed till move
> task (when the directory is actually moved). Care needs to be taken for deadlocks.
> 2. Versioning: The writer can create a new version if the current version is being read.
Note that, it is not equivalent to snapshots,
> the old version can only be accessed by the current readers, and will be deleted when
all of them have finished.
> Comments.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message