处理数据库事务和业务逻辑的最佳方法答案

【问题标题】：Best approach to handle database transactions and business logic处理数据库事务和业务逻辑的最佳方法
【发布时间】：2012-08-06 12:46:14
【问题描述】：

不知道这样处理数据库的事务是否正确：

    **locate database service**
         **open connection**
              **begin transaction**
                  get objects from relational database
                  call business logic
              **commit transaction**
         **close connection**
    **release**

星号中的代码将通过 IoC** 注入

虽然因此业务逻辑不受数据访问代码的影响，但询问实现是否正确以及可能带来的后果。

谢谢！

【问题讨论】：

标签： database transactions logic

【解决方案1】：

通常您不想在处理业务逻辑时保持事务打开。您的应用程序可能会执行冗长的计算、通过网络发送数据、调用远程服务等。在此过程中打开数据库事务会导致很多问题；其中一些是死锁、耗尽 RDMS 连接池、锁升级、丢失更新等。

一般来说，Repository 模块负责加载/持久化对象，包括事务管理。业务逻辑不必担心事务，它只需要知道如何调用 Repository 的正确方法。另外，请不要忘记，由于多种原因，存储数据可能会失败，因此请确保正确处理。例如，

1.从外部存储读取对象（事务管理，如果有的话，隐藏在存储库中）
2.根据业务逻辑操作对象
3.存储操作结果（假设你的存储是支持事务的RDMS，你开始事务，保存数据，成功提交，错误回滚）

【讨论】：

-1 使用单个数据库事务绑定业务逻辑对于确保数据库完整性至关重要。如果没有它，则无法保证您正在验证或保存的更改在您检查和保存期间仍然有效。
@kgrittn：有许多不同的方法可以确保保存的数据保持有效。长时间保持交易开放更危险。
我当然不提倡在等待用户输入的同时保持事务打开，但是业务逻辑的自动化应用通常不会在这应该成为问题的时间范围内。特别是，将业务逻辑应用于从数据库读取的内容（或由将相关数据写入数据库而触发）的结果写入数据库必须在同一事务中完成，以防止其他读取器看到不一致的数据库状态。
@kgrittn：单独使用事务并不能保证业务规则（除非它可以在db级别表示）。如果应用程序的所有部分都不使用serializable 隔离级别（这在服务器资源方面非常昂贵），那么与丢失更新相关的问题都无法解决。使用存储在数据库中的数据来调用远程（在许多情况下是第三方）Web 服务是很常见的。如果在这样的调用期间事务保持打开状态，这是走向灾难的第一步。数据库状态不应不一致，除非它是特定 RDMS 实现中的严重错误。
您在问题的什么地方看到任何关于业务逻辑涉及使用缓慢和/或不可靠资源的建议？诚然，当我们有必须这样做的事务时，我们有几秒钟的超时，如果我们达到超时，我们承诺将不完整的数据标记为处于错误状态，直到稍后可以重试事务，但我没有在问题中看不到任何需要处理此类问题的建议。

【解决方案2】：

定位数据库服务和打开通常希望保持连接打开以供重复使用的连接有足够的开销。如果在应用中不方便，连接池可以做到这一点。

【讨论】：