Enforce optimistic locking for upserts
See original GitHub issueUse case
When executing an insert with onDuplicateKeyUpdate
, optimistic locking is not enforced.
Describe the solution you’d like
The update executed as part of the upsert should enforce optimistic locking. Perhaps there should be options that allow it to be disabled similar to those for pure updates.
Versions
- Komapper: 1.4.0
- Kotlin: 1.7.10
- JVM: azul-13
- JDBC Driver or R2DBC Driver: R2DBC
- Database: Postgres 14.5-alpine
- OS: macos 12.6
Issue Analytics
- State:
- Created a year ago
- Comments:9 (4 by maintainers)
Top Results From Across the Web
Upsert with optimistic locking with DynamoDB and Boto3
I am trying to implement an upsert of an item into DynamoDB with optimistic locking. I have the update portion working with a ......
Read more >Database Locking Techniques with Ent - Entgo.io
Optimistic locking is commonly used in "low contention" environments (situations where the likelihood of two transactions interfering with one ...
Read more >Optimistic and pessimistic record locking - IBM
Optimistic locking allows multiple users to attempt to update the same record without informing the users that others are also attempting to update...
Read more >How to implement upsert-with-cas now? - Couchbase Forums
If you want to ensure optimistic locking : if you don't have a CAS, the only possibility is insert. if you do have...
Read more >Why does MYSQL use blocking locks instead of optimistic ...
Why isn't optimistic concurrency control more commonly supported at the database layer? It is a valid alternative and can completely do away ...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
That makes sense. It probably wouldn’t be a good idea for the behavior of
onDuplicateKeyUpdate()
to vary across the various databases and drivers. So I think this request can be closed, perhaps with just an additional note in the documentation ofonDuplicateKeyUpdate
that optimistic locking is not enforced. Appreciate your feedback on this issue! I will be sure and report anything else I come across, but so far working with Komapper has been excellent!Thanks for the quick reply. I would like to dig into the library a bit over the weekend to see how optimistic locking is implemented for update/deletes. Then, hopefully I can provide more detailed thoughts on behavior and implementation for this feature request.