Laravel: Avoid Race Conditions with Atomic Locks in Cache 

Atomic Locks saves me a lot of nerves :) I have an issue charging more than once the same invoice because have more than one instance on AWS and a loot of invoices. One cron job didn't finish and the second one triggered and at the same time, they charge the same invoice, then I find that out in the documentation and now all works awesome!

The beauty of Korop's videos is they bring to light topics that people generally don't know about; the use of examples is what adds the sugar 👏🏾

I think much better way is to use lockForUpdate() when selecting rows inside transaction. Second and other request can't select this rows while first transaction is't done. As I see default wait time is 50sec - then exception "General error: 1205 Lock wait timeout exceeded;". Be sure you are using lockForUpdate only inside transaction - other way it will no take effect.

Cool feature. I needed to implement this feature in an enterprise system that does not use Laravel and I went to read the Laravel source code. That helped a lot to implement it in my environment.

excellent way to show usage of this code. thanks

Thanks for this. Super helpful when handling transactions

Cool! My only concern is once again relying on seconds as a parameter for the action to be considered complete. It works however and I’m sure there is a way around that. Thanks for introducing the concept to us!

This doesn't seem like a great solution to me, as you need to specify the amount of seconds that the lock remains active. What would happen if for some reason you system is slower and a transaction exceeds for example the 10 seconds? Then you have the same issue as before. Could happen if you have a sudden influx of users that make your system slower then normal. What would be a more durable way to use this? Maybe setting the wait time higher? I believe the lock also releases when the operation is completed, but not sure.

I was thinking about this topic last week because i faced the same thing on project. Thanks 🙏

Thanks for the great example and tips. Just thinking about the lock principles. But wouldn't the shown lock example always lock any booking operation regardless it's the same booking operation? Would it now make more sense to have a qualified name for the lock to booking-by-{booking.date} to allow other booking operations to bypass the locking if there's no conflict potential (at least in case one can pretend if there may be a conflict)?

As always, it's great!!!!!!!!!!

apparently i did the same thing as you did but i cant seem to reproduce the issue before using the atomic lock

Very helpful.🙂

wow didnt know about atomic locks until now! thanks Povilas!

This code will stop all bookings even if it is in another date until the booking is done ? Or similar dates only ?

I can't produce the same result if lock has not used, how come the execution will wait for the job result ! (even it's inside a database transaction)? Am I missing something ?

Thanks for the information

Does an atomic lock need a duration time? In this case I would naively think user2 just needs to wait until user1 is done, no mater the duration of the process. Also, in your example you have your validation in the controller. I would like to place my validation in a validation request class. How would I do that while still keeping the lock code? Thanks for the example.

What happen if you put 20 seconds on your sleep function? You will have 2 successfull booking right ?

Thank you so much, i liked it 😃

Thank you so much.

Can the same be achieved with database locks?

Great!

Thanks

I love you sooo much

what about using form request?

I searched for a full year to know how to render (no internet) page, like youtube does, if a user enter youtube page with no internet, it will render no internet page, how to do it in laravel? is there any idea