lhofhansl has commented on the revision "
HBASE-5542 [jira] Unify HRegion.mutateRowsWithLocks() and HRegion.processRow()".
@Scott: Yes, it would make the API more complicated, which is not desirable.
Hmm... I cannot see any way around it for the general case, though. There are going to be operations that need to do some stuff without the locks held in the beginning and some stuff in the end.
On the other hand, if an operation has not pre/post tasks it would just not implement them (or implement no-ops)
So the overall flow of processRowsWithLocks would be something like:
2. -> run pre tasks (maybe these should return the rows to lock?)
3. acquire locks and start mvcc transaction
4. -> run the main operation... returns the KVs to use
5. apply the KVs to memstore and WAL (or should the main op be required to apply the KVs?)
7. sync wal
8. roll mvcc
9. -> run post tasks
(10. cleanup if needed)
-> denotes a callout to the row processor
Let's be careful that we get this right. It's also interesting to see whether we can fold doMiniBatchPut (or at least some aspects of it) into this. With the 3 phases it looks like this should possible (I'm happy to look at that separately)
Thanks for bearing with us Scott! This is awesome stuff.