Mutex lock/unlock step (to prevent race conditions)

Mutex lock/unlock step (to prevent race conditions)

Let’s start with an example:
Database Query user_balance: $10 (query takes e.g. 10ms)
If balance >= 10: Database Update user_balance: user_balance - $10
Database Query user_balance: $0

What happens if the same user performs the very same server action precisely at the same time? (e.g.: 1ms apart)

Database Query user_balance: $10
Database Query user_balance: $10
If balance >= 10: Database Update user_balance: user_balance - $10
If balance >= 10: Database Update user_balance: user_balance - $10
Database Query user_balance: $-10

A mutex lock step would allow a regular Wappler to prevent race conditions (such as the above). You would place a Lock step in the beginning of any time-critical portions of your app, followed by an Unlock at the end.

The mutex lock step would have associated an unlock step. For validation, Wappler UI should count if the number of Lock steps is equal to the number of the Unlock steps.

The mutex lock step would use an underlying filesystem LOCK_EX. This would only work on single-server deployments, not on clusters.

The mutex lock/unlock step would accept a user input (such as the user ID) as locking key.

Example of possible real-world use case: