1

从这个帖子。一个明显的问题是可扩展性/性能。交易使用还会引发哪些其他问题？

你能说有两组问题，一组是长期运行的事务，一组是短期运行的事务吗？如果是，您将如何定义它们？

编辑：死锁是另一个问题，但数据不一致可能会更糟，具体取决于应用程序域。假设一个值得交易的领域（银行，使用规范的例子），死锁的可能性更像是为确保数据一致性而付出的代价，而不是交易使用的问题，或者你会不同意？如果是这样，您将使用哪些其他解决方案来确保无死锁的数据一致性？

4

4 回答 4

2

即使不使用显式事务，也可能出现死锁。一方面，大多数关系数据库将对您执行的每条语句应用一个隐式事务。

死锁基本上是由获取多个锁引起的，任何涉及获取多个锁的活动都可能与涉及获取至少两个与第一个活动相同的锁的任何其他活动发生死锁。在数据库事务中，某些获取的锁可能会比其他情况下持有的时间更长——事实上，直到事务结束。持有的锁越长，发生死锁的机会就越大。这就是为什么一个运行时间较长的事务比一个较短的事务更有可能发生死锁。

于 2008-09-13T13:20:04.630 回答
2

它很大程度上取决于数据库内部的事务实现，也可能取决于您使用的事务隔离级别。我在这里假设“可重复读取”或更高。长时间保持事务打开（即使是没有修改任何内容的事务）会强制数据库保留经常更改的表的已删除或更新行（以防万一您决定读取它们），否则这些表可能会被丢弃。

此外，回滚事务可能非常昂贵。我知道在 MySQL 的 InnoDB 引擎中，回滚一个大事务可能需要比提交它更长的时间（我们已经看到回滚需要 30 分钟）。

Another problem is to do with database connection state. In a distributed, fault-tolerant application, you can't ever really know what state a database connection is in. Stateful database connections can't be maintained easily as they could fail at any moment (the application needs to remember what it was in the middle of doing it and redo it). Stateless ones can just be reconnected and have the (atomic) command re-issued without (in most cases) breaking state.

于 2008-11-02T12:25:14.713 回答
1

事务的一个问题是有可能（不太可能，但可能）在数据库中出现死锁。为了调试这些有趣/令人沮丧的问题，您必须了解您的数据库如何工作、锁定、事务等。

-亚当

于 2008-09-13T13:13:17.283 回答
0

我认为主要问题在于设计层面。我在我的应用程序中的哪个或多个级别使用事务。

例如我可以：

  • 在存储过程中创建事务，
  • 使用数据访问 API (ADO.NET) 控制事务
  • 在应用程序中使用某种形式的隐式回滚
  • （通过 DTC / COM+）中的分布式事务。

在同一应用程序中使用这些级别中的一个以上通常似乎会产生性能和/或数据完整性问题。

于 2008-09-13T13:18:03.263 回答