What happened:
Open Saves supports the update of record properties with the use of "atomic" messages to increment, decrement, add, subtract, and swap the property value.
What you expected to happen:
When multiple clients are incrementing a record property field simultaneously, I would expect the property value to be incremented by the number of clients that made the request.
How to reproduce it (as minimally and precisely as possible):
Using the Open Saves AtomicInc gRPC message, use 10 clients to increment a property field in the record at the same time. Some clients are going to be able to perform the operations, some others are going to fail with errors: concurrent transaction, signature mismatch, contention on entities.
Anything else we need to know?:
Since best practices suggest limiting the update on Datastore entities to 1 rps to avoid database contention, we might need to look into alternatives to implement this feature (Datastore won't cut it).
The Golang library Redsync provides a distributed lock that we could use to help implement a solution to ensure that:
All atomic operations on the same keys are completed regardless of the number of clients making simultaneous requests
We perform only one write per second on the target entity in Datastore
What happened: Open Saves supports the update of record properties with the use of "atomic" messages to increment, decrement, add, subtract, and swap the property value.
What you expected to happen: When multiple clients are incrementing a record property field simultaneously, I would expect the property value to be incremented by the number of clients that made the request.
How to reproduce it (as minimally and precisely as possible): Using the Open Saves AtomicInc gRPC message, use 10 clients to increment a property field in the record at the same time. Some clients are going to be able to perform the operations, some others are going to fail with errors: concurrent transaction, signature mismatch, contention on entities.
Anything else we need to know?: Since best practices suggest limiting the update on Datastore entities to 1 rps to avoid database contention, we might need to look into alternatives to implement this feature (Datastore won't cut it).
The Golang library Redsync provides a distributed lock that we could use to help implement a solution to ensure that:
Environment:
kubectl version):