Atomic is atomic and that’s not an issue. But if you’re locking a row… what are you locking?
The HFiles that make up the row? The CFs? The memory? How long do you hold the lock(s)? On Sep 12, 2014, at 9:29 PM, Stack <[email protected]> wrote: > On Fri, Sep 12, 2014 at 1:21 PM, Vladimir Rodionov <[email protected]> > wrote: > >> All row mutate operations in HBase are atomic: >> puts/deletes/increments/appends. >> Atomicity in HBase has the same meaning as in RDBMs exactly - operations >> completes as a whole or does not at all. There is an additional guarantee >> in HBase that all reads are ROW - atomic as well - one will never read >> partial result of atomic mutate operation (on a ROW). READ_UNCOMMITTED will >> weaken this read atomicity guarantee and it will be possible to read >> partial results of a row mutation operation, >> >> so we discard row read atomicity but still have cell atomicity >> (hopefully?). >> >> This is my understanding of what READ_UNCOMMITTED means in HBase. >> >> PS >> >> I created : >> https://issues.apache.org/jira/browse/HBASE-11965 > > > Thanks Vladimir, > St.Ack
