Replies: 2 comments
-
I kinda like this idea. |
Beta Was this translation helpful? Give feedback.
0 replies
-
I did all of this but as a wrapper wrapping fastcrud, hence, the customization question: #52 To prevent some form of guessing the concurrency version (by incrementation), I also did it with a guid that changes on each update. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Proposal of universal way of handling optimistic concurrency in db agnostic way
Each entity that supports concurrency check should have version column that is auto-incremented on update operation. Then update query should add concurrency check logic. If concurrency check fails operation should throw custom Exception (OptimisticConcurrencyException).
Pros: Dbms does not know nothing about this behaviour.
Version column is some number format (integer) and number of updates can be monitored be the db admin.
Implementation details:
Version column should be not null.
Treat column with name "Version" as a ConcurencyToken by convention.
Optional - add attribute ConcurencyToken to the column that will be use as concurrency token, which has different name than the convention.
Add method ConcurrentUpdate (or change the existing by adding optional boolean parameter) that before execution update query auto-increments current value of the Version field.
Extend query by adding optimistic concurrency check to it. Something like:
update Entity
set Name=@name
where Id=@id
and Version=@Version
If nothing is updated - throw OptimisticConcurrencyException.
Beta Was this translation helpful? Give feedback.
All reactions