Major Description
Currently, we try to acquire locks in whatever order the client passes the rows. This has two issues:
1) if the client passes the same row twice, it would deadlock on itself. This currently throws a LOG(FATAL).
2) if two clients pass a set of rows in opposite order, you can get a classic deadlock (A waiting on B, B waiting on A).
One option is to sort the incoming batches before acquiring locks, and check for duplicates after the sort. Another option is to do an algorithm like HBase:
while the request has more rows to insert/mutate: lock the first remaining row which hasn't been processed trylock the rest of the remaining rows run a transaction for all rows which successfully locked
This is deadlock-free and avoids any overhead from sorting.