Record level locking and latency

How Developers Are Using Aerospike How Aerospike Works
, ,
1

Hi,

we all know for consistency locking is required, I wanted to know what strategy does aerospike use to handle locking. I mean, I have an aerospike set with records. Will there be latency if I am trying to update a BIN for a PK (record) while reading or updating another BIN for the same PK (record). So, is there a record level lock or bin level locking is implemented.

Thanks!

2

Records are locked before being modified, so there is never a case where a read gets data that is partially modified. The changes are atomic.

See:

I also recommend that you read the architecture overview: https://www.aerospike.com/docs/architecture/index.html

3

So, basically if I am updating a bin for a record I will be unable to read some other bin for the same record till the lock is released by the first thread.

4

yes, it will put you in a queue until the lock is released. but… depending on your consistency requirements i think you can get around this. can you explain more in depth why this is a concern to you?

5

You can certainly read back another bin in the same thread that modified a bin in the same lock. See Operate().

6

To future readers, this model will likely change a bit with Aerospike 4.2.0.

During an update, a ‘record lock’ is held for the time required to read the record from either cache or storage-engine, merge with update, and write back to an in-memory buffer. The lock doesn’t cover the time for the buffer to flush to the storage-engine.

You can speed this up significantly if you are able to use the ‘replace’ policy when a record already ‘exists’. This policy replaces the record with the bins provided by the write allowing the write to bypass the read and merge portion of the write process. This wouldn’t be an option if your writes do not contain all of the bins on the record being written to - though if your records are not large it still may be faster to read all the bins and write them all back with a replace.

Also as @pgupta has mentioned, if you are reading and updating in the same transaction, look into ‘Operate’ and the ‘replace’ policy would still be beneficial if it fit your use case.

7

Thanks! I think I misunderstood the question.