hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lars Hofhansl (Issue Comment Edited) (JIRA)" <j...@apache.org>
Subject [jira] [Issue Comment Edited] (HBASE-3584) Allow atomic put/delete in one call
Date Sun, 15 Jan 2012 22:53:40 GMT

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

Lars Hofhansl edited comment on HBASE-3584 at 1/15/12 10:53 PM:
----------------------------------------------------------------

I noticed that there is a hole in my logic when faced with region server failures.

Since the WALEdits are applied to the WAL piece by piece what can happen is that the region
server applied the WALEdits of some of the mutations, and then dies before it can apply the
edits of the rest of the mutations.

The region server who is picking up the region will replay those edit and hence clients picking
up the KVs from the recovering region server will see the operation partially applied.
The fact that the MVCC write point was not forwarded by the first region server is irrelevant
and not known to the recovering region server.

Other operation (Increment/Append) also have correctness issues (albeit different) in failure
scenarios.

Filed HBASE-5203. Work on this would not be trivial. What's the general feeling: Disable this
feature until this is fixed? Or leave it enabled, since it is in principle not safer than
Increment or ICV?

                
      was (Author: lhofhansl):
    I noticed that there is a hole in my logic when faced with region server failures.

Since the WALEdits are applied to the WAL piece by piece what can happen is that the region
server applied the WALEdits of some of the mutations, and then dies before it can apply the
edits of the other mutations. The fact that the MVCC write point was not forwarded by the
first region server is irrelevant for this.

The region server who is picking up the region will replay those edit and hence clients picking
up the KVs from the recovering region server will see the operation partially applied.

Other operation (Increment/Append) also have correctness issues (albeit different) in failure
scenarios.

Filed HBASE-5203. Work on this would not be trivial. What's the general feeling: Disable this
feature until this is fixed? Or leave it is, since it is in principle not safer than Increment
or ICV?

                  
> Allow atomic put/delete in one call
> -----------------------------------
>
>                 Key: HBASE-3584
>                 URL: https://issues.apache.org/jira/browse/HBASE-3584
>             Project: HBase
>          Issue Type: New Feature
>          Components: client, coprocessors, regionserver
>            Reporter: ryan rawson
>            Assignee: Lars Hofhansl
>             Fix For: 0.94.0
>
>         Attachments: 3584-final.txt, 3584-v1.txt, 3584-v3.txt
>
>
> Right now we have the following calls:
> put(Put)
> delete(Delete)
> increment(Increments)
> But we cannot combine all of the above in a single call, complete with a single row lock.
 It would be nice to do that.
> It would also allow us to do a CAS where we could do a put/increment if the check succeeded.
> -----
> Amendment:
> Since Increment does not currently support MVCC it cannot be included in an atomic operation.
> So this for Put and Delete only.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message