> This will lock the affected row(s) in the context of the current transaction such that any other concurrent writes will fail.
Will fail or it will be waiting for release? If this will fail straightaway - would it be possible to differentiate locking error from other type of error.
In my opinion this aproach is less than desired
- It is very specific to database (as locking may work differently in other db's)
- Locking is slower than other queries
- Complex logic to detect actual errors
> 2. Optimistic Concurrency Control The basic idea is that your records have a version or timestamp column which you fetch as part of the initial read. Then when you write the new data you add a WHERE VERSION = expected version
I kinda seen this somewhere before :)
This aproach sounds familiar and we kinda have this timestamp already in form of clientVersion.
Question is how we "framework this" that users will have this where attached. If we chain knex and always attach where to updates it could be something that will
help us to hide complexity. Documentation/Resolver templates could be another option.
This aproach is way to go as can have benefits :
- It can be transformed to possibly any datasource (even the one that do not support transactions)
- Transactions itself will become redundant now - we can have read/write pattern.
- It's faster and easier to document
- Actual write will lock the table with other writes waiting for this to finish. |
|
