In the final iteration, this issue provides a generalized, public mutateRowsWithLocks method on HRegion, that can be used by coprocessors to implement atomic operations efficiently.
Coprocessors are already region aware, which makes this is a good pairing of APIs. This feature is by design not available to the client via the HTable API.
It took a long time to arrive at this and I apologize for the public exposure of my (erratic in retrospect) thought processes.
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.
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.