If you ever visit England and want to experience something unique, I recommend watching a Premier League game. You'll get to experience the distinc...
For further actions, you may consider blocking this person and/or reporting abuse
Great post, I am still a newbie to concurrency control but your post inspired me a lot. As a web developer, I see most of people only focus on single customer flow (ecommerce, booking, retailing, etc.), which is highly not applicable in real world
@jiasheng What is the difference with your OCC and zenstack example? you mention that is "simplified" but it looks the same, except some values in the prisma schema are added :)
Thanks for pointing it out! That's a silly copy/paste error I made.😂
There is an additional version filter you need to add in the occ version:
Wow, nice read!
I think I can just write a simple pure SQL transactions without thinking too much about an extra column overhead and then using zenstack to manage it.
I don't understand why people are keep on creating multiple different overhead and things to manage if that thing is just simply possible. Still if you need types just use kysely and build a query with FOR UPDATE and that's it.
Second of all the all these RBDMs actually handles these kind of transactions pessimistically so I don't think you need to handle this again optimistically and still if you want to do you can mark the transaction as serializable and handle it as a retry.
Thank you for sharing your perspective. Using row-level locking or serializable transactions, as you mentioned, is indeed a great solution. However, I also believe that OCC (Optimistic Concurrency Control) has its advantages in terms of performance and applicability. There is no one-size-fits-all answer in the software development world, and I think that's the beauty of the software development world
Software development is great and I understand everything has it's own tradeoffs but still there are many points I always consider before deploying a solution (specially for database layer work) in my application layer.
First of all, I will think about: can my database directly handle this things, if yes, is it better, fast and easier or which database will provide me a better solution for this architecture.
The real beauty of software development world is that there are so many ways to implement an architecture that's what I love about it and as I said everything has it's own tradeoffs.
I think if you want Optimistic concurrency control I would prefer using something like MongoDB or Casandra, even I can go with MySQL or Postgres. Doesn't real matter here (other then MongoDB) because I don't really have to think about the management of this new dependency and don't even need to think about the internal implementations.
This is my opinion, probably your have different takes on this thing.
While databases can handle tasks effectively, some individuals opt to include everything in their source code. It's similar to why fewer people are still using stored procedures nowadays, despite the benefits they offer. Additionally, I believe that is why our users prefer ZenStack over RLS of Postgres.
Understandable
Can we use userId= null condition instead of version?
It won't work because the operation needs to be non-idempotent, like the increment for version, in order to differentiate between different calls. Therefore If use userId= null, it is impossible to determine if the operation has been called once or multiple times.
@balajimut hope it could still reach you.
I just realized that the
userId=nullalso works for this case, which is both confirmed by the experiment and other experts. Sorry for my wrong conclusion before.