How to handle concurrent write to same bin from different clients?


#1

Hi there,

I’m pretty new to Aerospike. Could anyone explain the way Aerospike does to enforce concurrent write to the same bin if we want to concatenate the writing values?

Assume client1 write val1 to the bin and client2 writes val2 to the same bin at same time. How to enforce the results to be (val1, val2)?

Thank you in advance.


#2

Read and write transactions arriving concurrently to affect the same record will queue up. Updates to the record acquire a record lock ahead of modifying it, so there really is no case where two writes happen concurrently. The depth of this queue is controlled by the transaction-pending-limit, and by default it is 20. More than this number of concurrent transactions on the same record will return an error code 14, ‘key busy’. This is the so-called ‘hot key’ condition. Seach for hot key on the site for more information and solutions.

By default these two writes will be merged on the server-side. You can control this behavior through the exists write policy. You can also use the record’s generation to implement a check-and-set pattern to ensure that records do not get merged automatically on the server-side, but instead fail if another write came in before the one this client is trying.

I’ve used the python client for examples, but it happens on the server-side and any of the clients have these write policies.


#3

Thank you for your quick response.

I was not accurate in my previous post. The actual values write to the same bin are complex and can not be directly merged. So what the client side does in fact is fetch-modify-write. Can I use UDF to make these steps in one single atomic operation?