问题标签 [transactions]

假设我有一个名为 Companies 的表，它有一个 DepartmentID 列。还有一个包含 EmployeeID 列的部门表。当然，我也有一个 Employee 表。问题是我想删除一家公司，所以首先我必须删除每个部门的所有员工，然后是公司中的所有部门。级联删除不是一个选项，因此我希望使用嵌套事务。我是 SQL 新手，非常感谢您的帮助。

我有一个定期更新其数据库模式的程序。有时，其中一个 DDL 语句可能会失败，如果确实如此，我想回滚所有更改。我将更新包装在这样的事务中：

在我们执行时，如果其中一个语句失败，我会执行 ROLLBACK 而不是 COMMIT。这在 SQL Server 上效果很好，但对 Oracle 没有预期的效果。Oracle 似乎在每个 DDL 语句之后执行一个隐式 COMMIT：

• http://www.orafaq.com/wiki/SQL_FAQ#What_are_the_difference_between_DDL.2C_DML_and_DCL_commands.3F
• http://infolab.stanford.edu/~ullman/fcdb/oracle/or-nonstandard.html#transactions

有什么办法可以关闭这个隐式提交？

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

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

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

我有一个 applicationContext.xml 文件，它在 Spring 中间件自定义应用程序中配置了两个 org.springframework.orm.jpa.JpaTransactionManager （每个都有自己的持久性单元，不同的数据库）。

我想使用基于注释的事务（@Transactional），而不是搞乱 TransactionStatus 提交、保存和回滚。

一位同事提到，当有多个事务管理器时，即使上下文文件设置正确（引用转到正确的持久性单元），这样做也会感到困惑。有人见过问题吗？

在您的配置中，您会有两个事务管理器吗？你会有 txManager1 和 txManager2 吗？

这就是我在 JPA 中所拥有的，两个不同的 Spring bean 是事务管理器。

我在存储过程中有一个 SQL 插入查询，用于将行插入到链接服务器表中。

由于存储过程在父事务中被调用，因此此 Insert 语句尝试使用 DTC 将行插入链接服务器。

我想避免DTC 参与其中。

有什么方法可以让插入 SQL 语句忽略事务范围？

在当今时代，事务性编程是现代开发的主要内容。并发性和容错性对于应用程序的寿命至关重要，因此，事务逻辑已变得易于实现。但是，随着应用程序的增长，事务代码似乎对应用程序的可伸缩性变得越来越沉重，当您桥接分布式事务和镜像数据集时，问题开始变得非常复杂。我很好奇，在数据大小或应用程序复杂性方面，事务经常开始成为问题的根源（导致超时、死锁、关键任务代码中的性能问题等），这些问题的修复、故障排除更麻烦或解决方法，而不是设计一个本身更容错的数据模型，或使用其他方式确保数据完整性。此外，哪些设计模式可以最大限度地减少这些影响或使标准事务逻辑过时或成为非问题？

--

编辑：到目前为止，我们已经得到了一些质量合理的答案，但我想我会自己发布一个答案，以提出我听说过的一些事情，试图激发一些额外的创造力；我得到的大部分回应都是对这个问题的悲观看法。

另一个重要的注意事项是，并非所有死锁都是由于程序编码不当造成的。有时，任务关键型操作依赖于不同顺序的相似资源，或者不同查询中的复杂连接相互叠加；这是一个有时似乎不可避免的问题，但我一直参与重新设计工作流程，以促进不太可能导致问题的执行顺序。

当我发现事务日志只会正确截断时，我正在调查 SQL Server 2005 事务日志的快速增长 - 如果 sys.databases "log_reuse_wait" 列设置为 0 - 这意味着没有任何东西可以阻止事务日志重用现有空间.

有一天，当我打算备份/截断日志文件时，我发现该列在 tempdb 中有一个 4 或 ACTIVE_TRANSACTION。然后，我使用 DBCC OPENTRAN('tempdb') 和来自 sysprocesses 的 open_tran 列检查了任何打开的事务。结果是我在系统中的任何地方都找不到活动的交易。

log_reuse_wait 列中的设置是否准确？是否存在使用我上面描述的方法无法检测到的交易？我只是错过了一些明显的东西吗？

假设我有一个管理自己的事务的存储过程

如果我从现有事务中调用此 proc，则 proc 可以回滚外部事务。

如何在存储过程中正确确定事务的范围，以便存储过程不回滚外部事务？

我有一个无状态bean，例如：

典型的用法是客户端调用 processObjects(...)，它实际上并不与实体管理器交互。它做它需要做的事情，并为每个要处理的对象单独调用 process(...) 。process(...) 的持续时间相对较短，但 processObjects(...) 可能需要很长时间才能运行所有内容。因此我不希望它保持一个开放的交易。我确实需要单独的 process(...) 操作在他们自己的事务中操作。这应该是每次调用的新事务。最后，我想保持选项打开，让客户直接调用 process(...)。

我尝试了许多不同的事务类型：从不、不支持、支持（在 processObjects 上）和必需，需要新的（在进程上），但每次调用 merge() 时都会得到 TransactionRequiredException。

我已经能够通过将方法分成两个不同的 bean 来使其工作：

但我仍然很好奇是否有可能在一堂课上完成这项工作。在我看来，事务管理器仅在 bean 级别运行，即使为单个方法提供了更具体的注释也是如此。因此，如果我以某种方式标记一个方法以防止事务开始在同一实例中调用其他方法也不会创建事务，无论它们是如何标记的？

我正在使用 JBoss Application Server 4.2.1.GA，但欢迎/首选非特定答案。

我正在开发一个应用程序，该应用程序应该在收到 PayPal 即时付款通知时创建产品（如运输保险单）。不幸的是，PayPal 有时会发送重复的通知。此外，还有另一个第三方在从 PayPal 获取更新时同时执行 Web 服务更新。

这是所涉及的数据库表的基本图。

这是我想要做的基本图表：

如果有两个（或更多）线程（或进程或应用程序）同时执行此操作，我希望第一个线程在没有 policyID 时锁定“包”行，直到创建策略并分配 policyID到包装表。然后在将 policyID 分配给包表后，将释放锁。我希望调用相同代码的另一个线程在读取包行时会暂停，以确保它首先没有 policyID。当第一个事务的锁被释放时，我希望第二个事务将看到 policyID 在那里，因此返回而不在策略表中插入任何行。

注意：由于 CRUD 数据库设计，每个存储过程都涉及读取（选择）、创建（插入）或更新。

这是RepeatableRead事务隔离的正确使用吗？

谢谢。