[
https://issues.apache.org/jira/browse/HBASE-2294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12845634#action_12845634
]
Todd Lipcon commented on HBASE-2294:
------------------------------------
bq. I would also like to keep the term 'row lock' out - I think we could
possibly have serialized atomic updates to HBase without row locks (wow!).
+1. I'd also love to consider dropping the user-exposed row lock feature
entirely. This might be unpopular, but I think that feature is dangerous, and
compareAndSwap is an equally powerful concurrency primitive that's a lot less
complex. What do you guys think?
bq. One point of discussion, I think it's important to have a scanner stay 'up
to date' as much as possible
Also +1, I think the current compromise makes sense - don't see partial row
mutations, but at the beginning of each row, the freshest data is taken.
bq. The Map-reduce framework helps with this, with TIF you can read in one
pass, and TOF you write in another phase that are by necessity non-overlapping.
Not true of a map-only job, right?
bq. The more I think about it, the more I realize a user wants perfect
isolation, they should use Scan#setTimerange() - it supports everything you
want: restartable scanners, simple semantics, and cross-region support and has
an existing implementation
Again +1 :)
> Enumerate ACID properties of HBase in a well defined spec
> ---------------------------------------------------------
>
> Key: HBASE-2294
> URL: https://issues.apache.org/jira/browse/HBASE-2294
> Project: Hadoop HBase
> Issue Type: Task
> Components: documentation
> Reporter: Todd Lipcon
> Priority: Blocker
> Fix For: 0.20.4, 0.21.0
>
>
> It's not written down anywhere what the guarantees are for each operation in
> HBase with regard to the various ACID properties. I think the developers know
> the answers to these questions, but we need a clear spec for people building
> systems on top of HBase. Here are a few sample questions we should endeavor
> to answer:
> - For a multicell put within a CF, is the update made durable atomically?
> - For a put across CFs, is the update made durable atomically?
> - Can a read see a row that hasn't been sync()ed to the HLog?
> - What isolation do scanners have? Somewhere between snapshot isolation and
> no isolation?
> - After a client receives a "success" for a write operation, is that
> operation guaranteed to be visible to all other clients?
> etc
> I see this JIRA as having several points of discussion:
> - Evaluation of what the current state of affairs is
> - Evaluate whether we currently provide any guarantees that aren't useful to
> users of the system (perhaps we can drop in exchange for performance)
> - Evaluate whether we are missing any guarantees that would be useful to
> users of the system
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
