Details
-
Sub-task
-
Status: Open
-
Major
-
Resolution: Unresolved
-
None
-
None
-
None
Description
For secondary indexes, we have optimizations so that if multiple mutations are waiting on the same row lock, all subsequent mutations can re-use the previous mutation's final state and avoid an extra Get.
We can apply a similar idea to Phoenix sequences. If there's a "hot" sequence with multiple requests queueing for a Sequence row lock, we can consolidate them down to one set of Get / Put operations, then satisfy them all. This change is transparent to the clients.
Note that if this consolidation would cause the sequence update to fail when some of the requests would have succeeded otherwise, we should not consolidate. (An example is if a sequence has cycling disabled, and the first request would not overflow, but the first and second combined would. In this case we should let the first request go through unconsolidated, and fail the second request.)