On djangodocs it mentions that transaction.atomic() ensures atomicity but do not talk about locking.
Do transaction.atomic() locks DB while code inside transaction.atomic() is being executed or locks the rows of DB which are being processed inside code of transaction.atomic() ?
It depends on what your database isolation level is set to - you’ll need to look up that to work it out. In general, though, transactions do not lock database rows directly; they merely order table writes so they’re all done together if they’re from the same atomic block.
If you try and read and then write from two transactions simultaneously, some databases will take out a table lock and delay one transaction, some will allow the reads to not be fully serializable, and some will raise an error on write. It really depends!
1 Like
Thanks andrew!!!
Learned about select_for_update to lock DB rows which are being processed and if we want a lock on them till execution for them are not completed.