Web 应用程序应该使用显式 SQL 事务吗？答案

【问题标题】：Should web applications use explicit SQL transactions?Web 应用程序应该使用显式 SQL 事务吗？
【发布时间】：2008-10-07 08:28:25
【问题描述】：

考虑一个常规的 Web 应用程序，它主要对 SQL 数据库执行基于表单的 CRUD 操作。在这样的 Web 应用程序中是否应该有明确的事务管理？还是应该简单地使用自动提交模式？如果进行交易，“每个请求的交易”是否足够？

【问题讨论】：

【解决方案1】：

我只会在你做的事情实际上是事务性的时候使用显式事务，例如，发出几个高度相关的 SQL 命令。我想这方面的典型例子是银行应用程序——从一个账户取款并存入另一个账户必须始终成批成功或失败，否则有人会被骗！

我们在 SO 上使用交易，但只是很少使用。我们的大多数数据库更新都是独立的和原子的。很少有人具备上述银行业务示例的特性。

【讨论】：

【解决方案2】：

我强烈建议使用事务模式来保护数据完整性，因为自动提交模式会导致部分数据保存。

【讨论】：

【解决方案3】：

这通常在数据库接口层为我处理 - Web 应用程序很少在事务中调用多个存储过程。它通常调用一个存储过程来管理整个事务，因此Web应用程序只需要担心它是否会失败。

通常不允许 Web 应用程序访问其他事物（表、视图、内部存储过程），如果在尝试未包装在连接级别启动的事务中时，数据库可能会处于无效状态客户在致电之前。

Web 应用程序启动事务的情况也有例外，但它们通常很少见。

【讨论】：

【解决方案4】：

您应该使用事务，因为不同的用户将同时访问数据库。我建议你不使用自动提交。使用显式事务括号。至于每笔交易的解决方案，您应该将特定的工作单元括起来（无论这在您的上下文中意味着什么）。

您可能还想了解您的 SQL 数据库支持的不同事务隔离级别。他们将根据阅读用户看到的部分更新记录提供一系列行为。

【讨论】：

您能否提供任何应该使用事务而不使用自动提交的原因？除了处理 POST HTTP 请求、验证数据并通过单个 INSERT 或 UPDATE 将它们存储到数据库中之外，没有“工作单元”。
如果它真的是一个单一的 INSERT 或 UPDATE 那么你正在使用隐式事务。但是，使用显式事务是一个很好的习惯（出于上述原因），因为您不知道产品将来会如何发展。

【解决方案5】：

这取决于 CRUD 处理是如何完成的，当且仅当所有模型实例的创建和修改都在单个更新或插入查询中进行时，您可以使用自动提交。

如果您在多个查询模式下处理 CRUD（一个坏主意，IMO），那么您当然应该明确定义事务，因为这些查询肯定是“事务相关的”，您不希望以半模型结束在您的数据库中。这是相关的，因为一些 Web 框架出于各种原因倾向于以“多重查询”的方式来做事。

至于使用哪种事务模式，取决于您在数据视图方面可以支持什么（即，当客户看到数据时需要保持什么最新状态）以及在性能方面您必须支持什么。

【讨论】：

“在单个查询中完成”是什么意思？在自动提交模式下的 SQL Server 上，每个语句都被单独处理。见：msdn.microsoft.com/en-us/library/ms187878.aspx
我指的是应用程序。 “在单个查询中完成”是指模型的创建/修改是在单个更新/插入查询中进行的，而不是像某些框架最终那样在单独的查询中更新模型的每个部分。
这个位置意味着自动提交模式是可以的，只要应用程序发送一个批处理而不是单个语句。这是不正确的。在自动提交模式下，批处理中的每个语句都是单独执行的。在一批{StatementA}中； {声明B}； B 可能会失败，但 A 已经提交。

【解决方案6】：

最好在单个存储过程中插入/更新到多个表中。这样，就无需从 Web 应用程序管理事务。

【讨论】：