Does Aerospike lock the record before operating (read-Write) on the record? Or it uses optimistic concurrency control I.e uses generation while applying change?
The record is locked.
If record is locked then there shouldn’t be any reason to get the generation key exception? I noticed that operate returned GEN key mismatch exception. Please explain how this is possible.
Consider:
- Thread 1 reads record A at gen 1.
- Thread 1 sends an update for record A with gencheck 1.
- Thread 2 reads record A at get 1.
- Thread 2 sends an update for record A with gencheck 1.
- Thread 2’s request arrives at the server and is applied.
- Thread 1’s request arrives at the server and fails gencheck because the generation has changed.
when working with Expressions and operate there is still possibly of Genkey?
I thought we won’t have gen key failure because no one is reading/writing until this transaction complete.
If a thread is sending a write request with a gencheck and there are other apps or threads within the same app that may also be sending a write request to the same record then the application of some request can cause the gencheck of another to fail.
It is true that certain use-cases can reduce, or possibly eliminate, the need for gechcecks (and also this response code for such requests). The gechcheck methodology is typically used in the read/modify/write pattern. Without expressions and UDFs, this pattern requires two round trips to the server (one for the read and one for the write). Write expressions and udfs can contain the update instructions for an arbitrary record state which may eliminate the read round-trip.
If I haven’t answered your question, then it may help to have some example demonstrating what it is that you are trying to accomplish.
Are you suggesting that if we are only using write expression and operate to interact with a record, in this case we don’t have to worry about gen key?
Assuming no one is writing to this other than the one mentioned above ?
Yes, it is possible depending on how you have setup your operations. It may not make sense for all apps. The operations need to be provided in a way that retrying the same request after a prior try is applied results in the record’s bins not changing. It could be that the filterexp on the request filters if it detects that an app generated request id is already on the record. Another possibility is that the reapplied operation won’t change the bin state (idempotent).