MySQL: транзакции против таблиц блокировки

блокировка таблиц не позволяет другим пользователям БД влиять на заблокированные строки/таблицы. Но замки сами по себе не гарантируют, что ваша логика выйдет в согласованном состоянии.

подумайте о банковской системе. Когда вы оплачиваете счет онлайн, есть по крайней мере два счета, затронутые транзакцией: ваш счет, с которого берутся деньги. И счет получателя, на который перечисляются деньги. И банковский счет, на который они с радостью внесут все плата за обслуживание, взимаемая по сделке. Учитывая (как все знают в наши дни), что банки чрезвычайно глупы, скажем, их система работает следующим образом:

$balance = "GET BALANCE FROM your ACCOUNT";
if ($balance < $amount_being_paid) {
    charge_huge_overdraft_fees();
}
$balance = $balance - $amount_being paid;
UPDATE your ACCOUNT SET BALANCE = $balance;

$balance = "GET BALANCE FROM receiver ACCOUNT"
charge_insane_transaction_fee();
$balance = $balance + $amount_being_paid
UPDATE receiver ACCOUNT SET BALANCE = $balance

теперь, без блокировок и без транзакций, эта система уязвима к различным условиям гонки, самым большим из которых является несколько платежей, выполняемых на вашем счете или на счете получателя параллельно. В то время как ваш код имеет свой баланс восстановлен и делает huge_overdraft_fees() и еще много чего, это вполне возможно, что какой-то другой платеж будет работать с тем же типом кода параллельно. Они будут восстанавливать ваш баланс (скажем, $100), делать свои транзакции (вынимайте $20, которые вы платите, и $30, которые они вас обманывают), и теперь оба пути кода имеют два разных баланса: $80 и $70. В зависимости от того, какие из них заканчиваются последними, вы получите любой из этих двух остатков на своем счете вместо $ 50, которые вы должны были получить ($100 - $20 - $30). В данном случае - "банк ошибка в вашу пользу".

теперь, допустим, вы используете замки. Ваш платеж по счету ($20) попадает в трубу первым, поэтому он выигрывает и блокирует запись вашего счета. Теперь у вас есть эксклюзивное использование, и вы можете вычесть $20 из баланса, и написать новый баланс обратно в мире... и ваш счет заканчивается с $ 80, как и ожидалось. Но... ох... Вы пытаетесь обновить учетную запись получателя, и она заблокирована, и заблокирована дольше, чем позволяет код, тайм-аут вашей транзакции... Мы имеем дело с тупицей банки, поэтому вместо правильной обработки ошибок, код просто тянет exit(), и ваши $ 20 исчезают в облаке электронов. Теперь у вас нет $20, и вы все еще должны $20 приемнику, и ваш телефон будет возвращен.

так... ввод проводок. Вы начинаете транзакцию, вы дебетуете свой счет $20, вы пытаетесь кредитовать получателя с $20... и снова что-то взрывается. Но на этот раз, вместо exit(), код может просто сделать rollback, и пуф, ваши $ 20 волшебно добавлено обратно в ваш аккаунт.

В конце концов, это сводится к следующему:

блокировки удерживают кого-либо еще от вмешательства в любые записи базы данных, с которыми вы имеете дело. Транзакции удерживают любые "более поздние" ошибки от вмешательства в" более ранние " вещи, которые вы сделали. Ни один из них не может гарантировать, что все будет хорошо в конце концов. Но вместе они делают это.

в завтрашнем уроке: радость тупиков.