当MySQL / InnoDB发生死锁情况时,它会返回这个熟悉的错误:
'试图锁定时发现死锁;尝试重新启动事务'
所以我所做的就是记录进入事务的所有查询,以便在事务中的语句失败时可以简单地重新发出它们。简单。
问题:如果您的查询取决于之前查询的结果,则效果不佳。
例如:
START TRANSACTION;
INSERT INTO some_table ...;
-- Application here gets ID of thing inserted: $id = $database->LastInsertedID()
INSERT INTO some_other_table (id,data) VALUES ($id,'foo');
COMMIT;
在这种情况下,我不能简单地重新发布最初创建的事务。在事务失败后,第一个SQL语句获取的ID不再有效,但由第二个语句使用。同时,许多对象已经填充了来自事务的数据,然后在事务回滚时变得过时。当然,应用程序代码本身不会“回滚”数据库。
问题是:如何在应用程序代码中处理这些情况?(PHP)
我假设有两件事。如果您认为我走在正确的轨道上,请告诉我:
1)由于数据库不能在所有情况下逐字重新发布事务,因此我的原始解决方案不起作用且不应使用。
2)执行此操作的唯一好方法是将任何和所有发布事务的代码包装在其自己的try / catch块中,并尝试重新发出代码本身,而不仅仅是SQL。
感谢您的投入。你摇滚。
答案 0 :(得分:11)
交易可能会失败。死锁是一个失败的情况,你可能会在序列化级别中失败更多。交易隔离问题是一场噩梦。试图避免失败是我想的坏方法。
我认为任何编写良好的交易代码都应该为失败的交易做好准备。
正如您所看到的那样,记录查询并重放它们不是一种解决方案,因为当您重新启动事务时数据库已移动。如果它是一个有效的解决方案,SQL引擎肯定会为您做到这一点。对我来说,规则是:
这意味着重试循环。
所以你的try / catch块里面有交易。您需要添加while
循环,可能有3次尝试,如果代码的提交部分成功,则保留while循环。如果在3次重试后事务仍然失败,那么向用户启动一个Exception - 这样你就不会尝试无限的重试循环,事实上你可能会遇到一个非常大的问题 - 。请注意,您应该以不同的方式处理SQL错误和锁定或可序列化的异常。 3是任意数字,你可以尝试更多次尝试。
这可能会有类似的东西:
$retry=0;
$notdone=TRUE;
while( $notdone && $retry<3 ) {
try {
$transaction->begin();
do_all_the_transaction_stuff();
$transaction->commit();
$notdone=FALSE;
} catch( Exception $e ) {
// here we could differentiate basic SQL errors and deadlock/serializable errors
$transaction->rollback();
undo_all_non_datatbase_stuff();
$retry++;
}
}
if( 3 == $retry ) {
throw new Exception("Try later, sorry, too much guys other there, or it's not your day.");
}
这意味着所有的东西(读,写,功能)都必须包含在$do_all_the_transaction_stuff();
中。暗示事务管理代码位于控制器中,高级应用程序功能主代码,而不是分成几个低级数据库访问模型对象