有没有充分的理由不让您的申请处理任何交易？

Question

为什么人们不会在代码中进行交易管理？

当我提起弹簧/冬眠时，与一个非常紧张的dba交谈时出现了这个问题。我提到Spring可以处理事务，使用Hibernate映射表到对象等，并且问题出现了数据库（Oracle10g）已经处理事务管理，因此我们应该使用它。他甚至提出我们创建一堆数据库程序来执行插入/更新的想法，这样数据库可以更有效地处理事情，返回0/1判断插入/更新是否有效。

有没有充分的理由不让您的申请处理任何交易？我的dba是否一无所知？我在想他是，但是当我不确定答案时，我不是一位出色的演讲者...这就是为什么我要寻找答案的原因。

Answer 1

我认为这里存在一些误解。

关键是数据库不像Spring / Hibernate那样管理事务。

数据库通过提供事务行为“管理事务”，并且您的应用程序通过使用该行为和定义事务边界来“管理事务”（特别是在Spring或Hibernate的帮助下）。

由于事务边界由业务逻辑定义，因此在没有事务管理的情况下实现应用程序将要求您将所有业务逻辑移动到数据库端。即使您将简单的插入/更新操作实现为存储过程，只要应用程序需要定义应在同一事务中执行多个插入/更新，仅从事务管理中释放应用程序是不够的。

Answer 2

我不完全确定你是否意味着会有一堆crud存储过程（执行单个插入或更新），或者是否存在包含业务逻辑（事务脚本）的存储过程。如果你的意思是crud存储过程，那是一个非常糟糕的主意。 （实际上，即使你从crud方法开始，你最终也会因为业务逻辑的增加而使用事务脚本，所以它也是相同的。）如果你的意思是事务脚本，那么这就是某些方法所采用的方法。这是痛苦的，没有重用，你最终得到了一堆非常复杂的存储过程，非常难以测试。但DBA喜欢它，因为他们知道发生了什么。

还有一个论点（适用于事务脚本）它更快，因为往返次数较少，你有一次对存储过程的调用，并执行所有操作并返回结果，而不是通常的Spring / Hibernate应用程序，您有多个查询或更新，每个语句都通过网络传输到数据库（尽管Hibernate缓存并重新排序以尽量减少这种情况）。最小化网络往返可能是这种方法的最有效原因，您必须权衡是否值得牺牲灵活性来减少网络流量，或者是否是过早优化。

支持事务脚本的另一个论点是，正确实现系统所需的能力较低。特别是Hibernate的专业知识并不是必需的。您可以雇佣大量代码猴子并让他们敲响代码。所有硬物都从它们中移除并置于DBA的控制之下。

因此，回顾一下，以下是事务脚本的参数：

• 减少网络流量

• 廉价开发者

• 总DBA控制（从您的角度来看，他将是一个完全的瓶颈）

Answer 3

如上所述，没有办法从数据库的角度“使用事务”，而不会让你的应用程序在某些级别上意识到它。虽然，如果你使用的是Spring，你可以通过使用<tx:annotation-driven>并将@Transactional注释应用于服务实现类中的相关方法来轻松实现这一点。

也就是说，有时你应该绕过事务并直接写入数据库。特别是在速度比保证数据完整性更重要的任何时候。