我的应用程序从Java / Spring调用Oracle存储过程。没有Hibernate或iBatis或Spring JDBC模板。 这个服务器端/中间层是“瘦”的。从某种意义上说，没有业务逻辑检查，没有验证;它只是一种数据传输 UI和数据库之间的层。在数据检索或数据持久性的情况下，java代码调用存储过程。 存储过程是与各种表/表关系交互并聚合数据的大家伙。
问题 - 在这种情况下，谁应该理想地管理交易？从Java代码或存储过程？
通常当中间层管理数据或执行业务逻辑，或者验证时，我们要么使用普通的JDBC / ORM框架来 与各种表交互，因此也管理交易。 但在我的用例中，SP正在与表进行交互，决定数据是否被正确检索或能够持久存在， 为什么它应该依靠中间层来单独管理交易。它可以很好地知道是提交事务还是回滚它。
在数据检索的情况下，总是编写一个SP作为聚合函数的高级接口，不是更好吗？ 或者在数据持久化的情况下汇总函数，最后做一个事务提交或事务回滚？
只有在预计会调用多个SP时，中间层才需要处理事务管理 对于特定的操作。只要java代码仅针对特定操作[fetch / update / delete]调用SINGLE存储过程， 在存储过程本身中管理事务提交和回滚是不是很好？
如果SP内部出现问题，它可以回滚事务并引发异常，以及Java 然后会传递该异常消息[或记录并将自定义异常传递给UI。
反问题是让SP在遇到任何异常的情况下引发异常，并且Java代码反过来捕获异常并执行事务回滚。 如果在调用SP时没有异常，则让它进行事务提交。 但是在这里，SP已经知道交易是成功还是失败，那么为什么我们不能自己做提交或回滚，而是 以异常或无异常的形式传递该信息，让java代码执行提交/回滚？
更新：证明需要Java代码来管理事务的一件事是它为一个SINGLE操作调用MULTIPLE SP。 但是，同样的结果可以通过一个高级例程来实现，该例程执行内部调用各个例程的逻辑，最后 采取提交/回滚的决定。
请分享您对此的想法/建议/设计建议。
PS：我还没有在这里分享任何代码，但这是一个程序设计问题，关于谁应该管理交易？
答案 0 :(得分：1)
这是一个哲学问题。 这里没有更好的选择，这取决于您的偏好和专业领域。
DBA会喜欢存储程序方法java程序员不会。
关于事务管理，我更喜欢统一的方法评估者，然后是混合解决方案。 事务管理很复杂，如果您使用SP使用数据库事务管理，我宁愿坚持使用一种方法。如果您选择使用jdbc或ORM，请使用jdbc事务管理或spring抽象来进行jdbc trx管理。
SP方法有其优点和缺点：亲：
<强>缺点：
无论如何，我会使用spring JDBC Template，从我的角度来看，这是一个很好的JDBC抽象，可以节省样板代码和错误。
如果你去进行java事务管理，我将添加Spring PlatformTransactionManager。
添加spring-jdbc和spring-tx jar不会产生巨大的效果。 这两个罐子大约是800k，我想还会添加一些额外的依赖罐子。