有什么充分的理由不让您的应用程序处理任何交易吗？
是否有任何充分的理由说明为什么人们不在其代码中进行事务管理？
这个问题是在与一位 dba 交谈时提出的，当我提到 spring/hibernate 时，他会非常紧张。我提到 Spring 可以处理事务，与 Hibernate 映射表到对象等一起使用，并且出现的问题是数据库（Oracle10g）已经处理事务管理，所以我们应该使用它。他甚至提出了这样的想法：我们创建一堆数据库过程来执行插入/更新，以便数据库可以更有效地处理事情，并在插入/更新是否有效时返回 0/1。
有什么充分的理由不让您的应用程序处理任何交易吗？难道我的dba一无所知吗？我想他是，但当我不确定答案时，我不是一个出色的演讲者……这就是为什么我出去寻找答案。
Are there any good reasons why one would not have transaction management in their code?
The question came up when talking with a dba who gets very nervous when I bring up spring/hibernate. I mention that Spring can handle transactions, in use with Hibernate mapping tables to objects etc, and the issue comes up that the database(Oracle10g) already handles transaction management, so we should just use that. He even offered up the idea that we create a bunch of DB procedures to do inserts/updates so the database can handle things more efficiently, returning a 0/1 on whether the insert/update worked.
Are there any good reasons to not have your application deal with any transactions? Is my dba clueless? I'm thinking he is, but I'm not a great speaker when I'm unsure of the answer... which is why I'm out looking for the answer.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我认为这里存在一些误解。
关键是数据库并不像 Spring/Hibernate 那样管理事务。
数据库通过提供事务行为来“管理事务”，而您的应用程序通过使用该行为并定义事务边界（特别是在 Spring 或 Hibernate 的帮助下）来“管理事务”。
由于事务的边界是由业务逻辑定义的，因此在没有事务管理的情况下实现应用程序将需要将所有业务逻辑移至数据库端。即使您将简单的插入/更新操作实现为存储过程，只要应用程序需要定义应在同一事务内执行多个插入/更新，那么将应用程序从事务管理中解放出来也不够。
I think there is some misunderstanding here.
The point is that database doesn't manage transactions in the same sense as Spring/Hibernate.
Database "manages transactions" by providing transactional behaviour, and your application "manages transactions" by using that behaviour and defining transaction boundaries (in particular, with the help of Spring or Hibernate).
Since boundaries of transactions are defined by business logic, implementing an application without transaction management would require you to move all your business logic to the database side. Even if you implement simple insert/update operations as stored procedures, it won't be enough to free application from transaction management as long as application needs to define that several inserts/updates should be executed inside the same transaction.
我不完全确定您的意思是存在一堆临时存储过程（执行单个插入或更新），还是存在包含业务逻辑（事务脚本）的存储过程。如果您指的是 CRUD 存储过程，那完全是个坏主意。 （实际上，即使您从 CRUD 方法开始，随着业务逻辑的增加，您最终也会得到事务脚本，因此这相当于同一件事。）如果您指的是事务脚本，那么这是某些地方采用的方法。这是痛苦的，而且没有重用，最终会得到一堆非常复杂的存储过程，而且非常难以测试。但 DBA 喜欢它，因为他们知道发生了什么。
还有一个论点（适用于事务脚本）认为它更快，因为往返次数更少，您只需调用一次存储过程即可执行所有操作并返回结果，这与您通常的 Spring/Hibernate 应用程序相反。有多个查询或更新，并且每个语句都通过网络到达数据库（尽管 Hibernate 会缓存并重新排序以尽量减少这种情况）。最小化网络往返可能是这种方法最有效的原因，您必须权衡是否值得为了减少网络流量而牺牲灵活性，或者是否是过早的优化。
支持事务脚本的另一个论点是，正确实施系统所需的能力较少。特别是不需要 Hibernate 专业知识。你可以雇佣一群代码猴子，让他们敲出代码。所有困难的东西都被移除并置于 DBA 的控制之下。
因此，回顾一下，以下是事务脚本的论点：
更少的网络流量
廉价的开发人员
总体 DBA 控制（从您的角度来看，他将是一个彻底的瓶颈）
I am not entirely sure if you mean that there will be a bunch of crud stored procedures (that do single inserts or updates), or if there will be stored procedures encompassing business logic (transaction scripts). If you mean the crud stored procedures, that is an entirely bad idea. (Actually even if you start with the crud approach you will end up with transaction scripts as business logic accretes, so it amounts to the same thing.) If you mean transaction scripts, that's an approach some places take. It is painful and there is no reuse, and you end up with a bunch of very complex stored procedures that are terribly hard to test. But DBAs like it because they know what's going on.
There is also an argument (applying to Transaction Scripts) that it's faster because there are less round trips, you have one call to the stored procedure that goes and does everything and returns a result, as opposed to your usual Spring/Hibernate application where you have multiple queries or updates and each statement is going over the network to the database (although Hibernate caches and reorders to try to minimize this). Minimizing network round-trips is probably the most valid reason for this approach, you have to weigh whether it is worth sacrificing flexibility for the reduced network traffic, or if it is a premature optimization.
Another argument made in favor of transaction scripts is that less competence is required to implement the system correctly. In particular Hibernate expertise is not required. You can hire a horde of code monkeys and have them bang out the code. All the hard stuff is removed from them and placed under the DBA's control.
So, to recap, here are the arguments for transaction scripts:
Less network traffic
Cheap developers
total DBA control (from your point of view, he will be a total bottleneck)
如上所述，从数据库的角度来看，如果不让您的应用程序在某个级别上意识到它，就无法“使用事务”。不过，如果您使用 Spring，则可以通过使用
@Transactional注释应用于相关方法来使此过程变得相当轻松。服务实现类。也就是说，有时您应该绕过事务并直接写入数据库。特别是在速度比保证数据完整性更重要的任何时候。
As mentioned above, there's no way to "use transactions" from the database standpoint without making your application aware of it at some level. Although, if you're using Spring, you can make this fairly painless by using
<tx:annotation-driven>and applying the@Transactionalannotations to the relevant methods in the service implementation classes.That said, there are times when you should bypass transactions and write directly to the database. Specifically any time when speed is more important than guaranteed data integrity.