You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Early in the process of product edition we could acquire the lock product using it's id (eventually waiting). We can fail in case we can't get the lock. Lock should timeout after a small amount of time (case of killed worker), maybe 5s. In case we are stuck for too long, we can decide to fail (mobile app will retry the edit).
The text was updated successfully, but these errors were encountered:
What
We currently have a lock mechanism only at the store point for sto files.
But we can have concurrent requests (the mobile app is very atomic) which introduces inconsistencies.
We could have a lock mechanism to avoid concurrent writes to the sto file.
Redis has good primitives to support that in multi-process situations. https://github.com/sbertrang/redis-distlock might be an interesting implementation.
Early in the process of product edition we could acquire the lock product using it's id (eventually waiting). We can fail in case we can't get the lock. Lock should timeout after a small amount of time (case of killed worker), maybe 5s. In case we are stuck for too long, we can decide to fail (mobile app will retry the edit).
The text was updated successfully, but these errors were encountered: