[
https://issues.apache.org/jira/browse/HBASE-5229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13202684#comment-13202684
]
[email protected] commented on HBASE-5229:
------------------------------------------------------
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3748/
-----------------------------------------------------------
(Updated 2012-02-07 19:41:16.600336)
Review request for hbase.
Changes
-------
This is essentially the same patch with the following differences:
* all changes to HTable, HTableInterface, HRegionServer, HRegionInterface
removed
* internalMutate made public and renamed to mutateRowsWithLocks
The idea is that mutateRowsWithLocks is only available to coprocessors, and not
to the client HTableInterface API.
Coprocessors already need to be region aware, so this is a nice match of APIs.
The test classes MulitRowMutationProtocol and MulitRowMutationEndPoint serve as
an example of how to do that.
TestFromClientSide.testMultiRowMutation illustrates how the client API would
like (once a coprocessor is in place)
Summary
-------
This builds on HBASE-3584, HBASE-5203, and HBASE-5304.
Multiple Rows can be locked and applied atomically as long as the application
ensures that all rows reside in the same Region (by presplitting or a custom
RegionSplitPolicy).
At SFDC we can use this to colocate subsets of a tenant's data and allow atomic
operations over these subsets.
Obviously this is an advanced features and this prominently called out in the
Javadoc.
This addresses bug HBASE-5229.
https://issues.apache.org/jira/browse/HBASE-5229
Diffs (updated)
-----
http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
1241350
http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java
1241350
http://svn.apache.org/repos/asf/hbase/trunk/src/test/java/org/apache/hadoop/hbase/client/MultiRowMutationEndpoint.java
PRE-CREATION
http://svn.apache.org/repos/asf/hbase/trunk/src/test/java/org/apache/hadoop/hbase/client/MultiRowMutationProtocol.java
PRE-CREATION
http://svn.apache.org/repos/asf/hbase/trunk/src/test/java/org/apache/hadoop/hbase/client/TestFromClientSide.java
1241350
http://svn.apache.org/repos/asf/hbase/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/TestAtomicOperation.java
1241350
Diff: https://reviews.apache.org/r/3748/diff
Testing
-------
Tests added to TestFromClientSide and TestAtomicOperation
Thanks,
Lars
> Explore building blocks for "multi-row" local transactions.
> -----------------------------------------------------------
>
> Key: HBASE-5229
> URL: https://issues.apache.org/jira/browse/HBASE-5229
> Project: HBase
> Issue Type: New Feature
> Components: client, regionserver
> Reporter: Lars Hofhansl
> Assignee: Lars Hofhansl
> Fix For: 0.94.0
>
> Attachments: 5229-endpoint.txt, 5229-multiRow-v2.txt,
> 5229-multiRow.txt, 5229-seekto-v2.txt, 5229-seekto.txt, 5229.txt
>
>
> HBase should provide basic building blocks for multi-row local transactions.
> Local means that we do this by co-locating the data. Global (cross region)
> transactions are not discussed here.
> After a bit of discussion two solutions have emerged:
> 1. Keep the row-key for determining grouping and location and allow efficient
> intra-row scanning. A client application would then model tables as
> HBase-rows.
> 2. Define a prefix-length in HTableDescriptor that defines a grouping of
> rows. Regions will then never be split inside a grouping prefix.
> #1 is true to the current storage paradigm of HBase.
> #2 is true to the current client side API.
> I will explore these two with sample patches here.
> --------------------
> Was:
> As discussed (at length) on the dev mailing list with the HBASE-3584 and
> HBASE-5203 committed, supporting atomic cross row transactions within a
> region becomes simple.
> I am aware of the hesitation about the usefulness of this feature, but we
> have to start somewhere.
> Let's use this jira for discussion, I'll attach a patch (with tests)
> momentarily to make this concrete.
--
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
