使用事务而不实际进行任何查询是否会产生资源成本？

Question

好吧，因此我们的团队成员之一建议，在每个http请求的开始处，我们开始一个数据库事务（我们正在使用Entity Framework Core），执行请求的工作，然后如果响应为，则完成事务。 200好，否则回滚。

这意味着我们只会在成功的请求上提交。

当我们执行对数据库的读写操作时，这很好。

但是我想知道，如果我们实际上不对数据库进行任何读取或写入，这会付出一定的代价吗？

Answer 1

如果为此使用TransactionScope，则仅在第一次数据库访问时才实际打开事务。未使用的示波器的成本非常低。

如果您使用普通的EF交易，那么一个空交易将击中数据库三次：

1. BEGIN TRAN
2. 提交
3. 重置连接以进行连接池

每一种成本都非常低。您可以通过简单地循环运行100000次来测试其成本。您可能根本不在乎这么小的成本。

我仍然不建议这样做。以我的经验，与Web请求和事务的1：1对应关系相比，Web应用程序需要更大的灵活性。同样，使用HTTP状态代码来决定交易的规则也变得不灵活。

此外，您必须为每个事务选择隔离级别（可能还有超时）。在HTTP请求开始时，不知道正确的值是什么。只有动作知道。

我对每个HTTP请求使用一个EF上下文，然后在每个操作中手动使用事务有很好的经验。就LOC而言，开销非常小。迫切需要将其集中起来。

Answer 2

不要盲目地将BEGIN...COMMIT放在所有内容周围。在某些情况下，这只是错误。

如果网页记录了用户的存在或特定页面的加载，该怎么办？拥有ROLLBACK会破坏该信息。

如果页面上有两个操作，并且它们彼此独立，该怎么办？那是ROLLBACK，因为其中一个还可以，但是您想COMMIT是另一个？

如果页面上没有写内容怎么办？则不需要BEGIN...COMMIT。