Hi sir i have seen one of your video related to transactions(WAL) can you create one video which can explain the relation between the locks used by transactions and optimistic and pessimistic locks(actual question is why we need these optimistic and pessimistic locking if we already have transaction isolation levels)
Hi Narendra, thank you very much Narendra. These videos are really helpful. Could please make some video on System design of paytm or phonePe or googlePay ? it would be a great help to many of us .
optimistic or pessimistic locks are application level decision, so saying that pessimistic locks are for RDBMS is not right. You can pessimistic locks implemented in NoSQL DB, same ways optimistic in RDBMS.
When there are very few clahes, how optimistic lock is more useful, wouldn't pessimistic be useful? As no-other can edit but read, as there are less clashes, there will be no one updating so we can lock. ? I am bit confused.
Aren't the concepts really more of "Pessimistic locking" and "Optimistic concurrency"? I've never heard it referred to as Optimistic locking since the whole point is that it's not locking but rather validating that the mutation is still safe based on criteria like versioning.
Well, my first reaction here was "its lock, not control whether pessimistic or optimistic" but as more I explored, yeah this is the case - "Pessimistic locking" and "Optimistic concurrency (control mechanism with versioning, if you will)". Yep!
Question : How optimistic lock handles concurrency? If multiple threads are trying to update against a same version number then how the correctness of the system will retain?
Apart from pessimistic locking way, this can be achieved by optimistic locking also, you can read about MVCC. Many DBs like Postgress uses this approach.
My team generally handles it with some sort of retry policy wrapping the processes which also enforce some basic validations. If the update fails since some other process concurrently updated the record, then you need to re-read the record and then if the update is no longer safe, it should be enforced by the common set of validations that each process would have had to enforce.
When we use frameworks like rails and start a transaction, like ActiveRecord::Base.transaction should it not acquire locks by default on the affected rows.? My question why transactions and acquiring locks cant go hand in hand ?
Surely it depends on your use case (which he explains in the video). You can get locks on anything, but should you? What impact will that have on your users?
But with optimistic lock you still have to perform an atomic read and write (read version to check, and then update version and write new data within same transaction). So I don't understand the point. Am I misunderstanding something? Edit: Oh I see, you only acquire the lock when you are done processing the new data that should be written. I would have thought that's how people always did it.
No, because the editing thread will lock that record and the other thread that is trying to edit it as well will get blocked. The optimistic locking requires a version (or timestamp) to do the rollback of that active transaction
Thanks for the video. One question: assuming version 1 data is n, process 1(want to +1) and 2 (want to +2) both validate that it is safe to write since version has not changed, the slow writer will operate on stale data(since the fast writer finishes writing first). How do optimistic locking solve this issue?
Charlie Zhang Both processes will read the data at version 1, write the new value into their own write buffer in parallel. However at commit stage, one of the processes will succeed in updating the data, which will be the version after the commit. and another process will be aborted because it read data at version 1 which does not match version at commit time and have to retry its transaction
I @tech Dummies, i'm a front-end developer, i got a look question in my system design and i wasn't able to answer it. do you think is something that can affect my interview result?
How can optimistic lock solve the problem of 2 or more concurrent connections not updating the version to a different one after checking the versions simultaneously ?
Man "kind of..." "like..." .etc are not precise technical terms...contention would do the job, concurrency etc your tutorial is mediocre in terms of quality of explaining those important topics in a succinct and clear technical terms.
How do you know that pessimistic lock is mostly used ? Do you have any data, stats to prove it ? I guess not...so you statement is not valid, sucks ok, ok....ok :-)
Great explanation, thank you sir.
Very nice and detailed explanation !!. Thank you
my friend you are so GREAT !!
great content thank you sir
Great explanation 👍
Good explanation!
Nice video!!!
Very well explained!
awesome explanation. I will save this video for the next time I need to check this out. The rule of thumb is a lifesaver as well
Thanks, Narendra! Your tutorials have always been good.
thanks Narendra i helps a lot me to understand locks on DB
very clear and concise
clear like water! thanks bro!
What an excellent video! You explaination is very perspicuous and examples are very practicle. Keep going! 😉
Amazing explanation.Thanks :)
Great as usual
Interesting and clear as usual! Thank you, Narendra!
Awesome!!! Please keep uploading videos. They are helping a lot...!!!!:)
Yah right.u r doing a fantastic job for free.plz keep it up. We r really grateful......its really helps.sharing is caring.
Interesting
good content
thumbs up
nice
Nice explanation
Clear explanation! Thanks.
8.40 Rq 1 finishes last, Rq 2 finishes first ... how to find the latest data? will it not be wrong to change 17 to 14?
Hi sir i have seen one of your video related to transactions(WAL) can you create one video which can explain the relation between the locks used by transactions and optimistic and pessimistic locks(actual question is why we need these optimistic and pessimistic locking if we already have transaction isolation levels)
Thanks!
If an optimistrick exception is raised then what we do. Can we write some sort of retry logic for the same transaction ??
Please use a good sound recording device, the sound is suppressed with lot of noise.
Hi Narendra, thank you very much Narendra. These videos are really helpful.
Could please make some video on System design of paytm or phonePe or googlePay ? it would be a great help to many of us .
Why optimistic is even termed as a lock?
Awesome! Thanks for a really clear explanation.
optimistic or pessimistic locks are application level decision, so saying that pessimistic locks are for RDBMS is not right. You can pessimistic locks implemented in NoSQL DB, same ways optimistic in RDBMS.
Please make video on: System Design of Version Control System like git
When there are very few clahes, how optimistic lock is more useful, wouldn't pessimistic be useful? As no-other can edit but read, as there are less clashes, there will be no one updating so we can lock. ? I am bit confused.
How to handle conflicts in case of optimistic locks ?
could please explain what is a live lock mean??
Aren't the concepts really more of "Pessimistic locking" and "Optimistic concurrency"? I've never heard it referred to as Optimistic locking since the whole point is that it's not locking but rather validating that the mutation is still safe based on criteria like versioning.
Well, my first reaction here was "its lock, not control whether pessimistic or optimistic" but as more I explored, yeah this is the case - "Pessimistic locking" and "Optimistic concurrency (control mechanism with versioning, if you will)". Yep!
Question : How optimistic lock handles concurrency? If multiple threads are trying to update against a same version number then how the correctness of the system will retain?
You will need to use pessimistic lock/ transaction there. Because you are reading n updating.
Apart from pessimistic locking way, this can be achieved by optimistic locking also, you can read about MVCC. Many DBs like Postgress uses this approach.
My team generally handles it with some sort of retry policy wrapping the processes which also enforce some basic validations. If the update fails since some other process concurrently updated the record, then you need to re-read the record and then if the update is no longer safe, it should be enforced by the common set of validations that each process would have had to enforce.
So optimistic lock also need a lock before verifying version and updating data, but lock period is shorter, right?
When we use frameworks like rails and start a transaction, like ActiveRecord::Base.transaction should it not acquire locks by default on the affected rows.?
My question why transactions and acquiring locks cant go hand in hand ?
Surely it depends on your use case (which he explains in the video). You can get locks on anything, but should you? What impact will that have on your users?
But with optimistic lock you still have to perform an atomic read and write (read version to check, and then update version and write new data within same transaction). So I don't understand the point. Am I misunderstanding something?
Edit: Oh I see, you only acquire the lock when you are done processing the new data that should be written. I would have thought that's how people always did it.
how to handle OPTIMISTIC LOCKING with shading and clusters ?
Very clear . Thanks . Does pessimistic lock require version and timestamp . If yes then why
No, because the editing thread will lock that record and the other thread that is trying to edit it as well will get blocked.
The optimistic locking requires a version (or timestamp) to do the rollback of that active transaction
Thanks for the video. One question: assuming version 1 data is n, process 1(want to +1) and 2 (want to +2) both validate that it is safe to write since version has not changed, the slow writer will operate on stale data(since the fast writer finishes writing first). How do optimistic locking solve this issue?
Charlie Zhang Both processes will read the data at version 1, write the new value into their own write buffer in parallel. However at commit stage, one of the processes will succeed in updating the data, which will be the version after the commit. and another process will be aborted because it read data at version 1 which does not match version at commit time and have to retry its transaction
I @tech Dummies, i'm a front-end developer, i got a look question in my system design and i wasn't able to answer it. do you think is something that can affect my interview result?
If you are not a full stack developer, I don't see a point in asking system design question.
But I would expect you to understand Design patterns
How can optimistic lock solve the problem of 2 or more concurrent connections not updating the version to a different one after checking the versions simultaneously ?
There will be a local transaction which stops from version conflicts
Audio quality is not good.
come on man, please listen to your video, do some editing before uploading
Man "kind of..." "like..." .etc are not precise technical terms...contention would do the job, concurrency etc your tutorial is mediocre in terms of quality of explaining those important topics in a succinct and clear technical terms.
How do you know that pessimistic lock is mostly used ? Do you have any data, stats to prove it ? I guess not...so you statement is not valid, sucks ok, ok....ok :-)
Didn't like