我的应用程序从Java/Spring调用Oracle存储过程。没有Hibernate、iBatis或Spring JDBC模板。这个服务器端/中间层是"瘦"的，因为没有业务逻辑检查，没有验证；它只是一个数据传输UI和数据库之间的层。java代码在数据检索或数据持久性的情况下调用存储过程。存储过程是与各种表/表关系交互并聚合数据的大人物。
问题-在这种情况下，谁应该理想地管理交易？从Java代码还是从存储过程
通常，当中间层管理数据或进行业务逻辑或进行验证时，我们会使用普通的JDBC/ORM框架与各种表交互，从而管理事务。但在我的用例中，SP与表交互，决定数据是否正确检索或是否能够持久存在，为什么它要依赖中间层来单独管理事务。它可以很好地知道是提交事务还是回滚事务
在数据检索的情况下，总是编写一个充当聚合函数高级接口的SP不是更好吗，或者在数据持久性的情况下使用summary函数，最后执行事务提交或事务回滚？
只有当期望调用多个SP时，中间层才需要处理事务管理用于特定操作。只要java代码仅针对特定操作调用SINGLE存储过程[fetch/update/delete]，在存储过程本身中管理事务提交和回滚不是很好吗？
如果SP内部出现问题，它可以回滚事务并引发异常，Java然后将该异常消息[或将其记录并传递自定义异常]到UI。
一个相反的想法是，在遇到任何异常的情况下，让SP引发一个异常，然后Java代码捕获该异常并执行事务回滚。如果调用SP没有异常，则让它执行事务提交。但在这里，SP已经知道了事务是成功还是失败，然后是为什么我们不能执行提交或回滚，然后是它自己，而是以异常或无异常的形式传递信息，并让java代码执行提交/回滚？
update：当Java代码为SINGLE操作调用MULTIPLE SP时，有一件事证明了需要Java代码来管理事务。但是，同样的结果也可以通过一个高级例程来实现，该例程执行内部调用单个例程的逻辑，最后做出提交/回滚的决定。
请分享您对此的想法/建议/设计建议。
附言：我在这里没有分享任何代码，但这是一个程序设计问题，关于谁应该管理事务？
这是一个哲学问题。没有比这更好的了——这取决于你的喜好和你的专业领域。
DBA会喜欢java程序员不会的存储过程方法。
关于交易管理，我更喜欢统一的评分方法，而不是混合解决方案。事务管理很复杂，如果您使用SP使用数据库事务管理，我更倾向于使用一种方法。如果您选择使用jdbc或ORM，请使用jdbc事务管理或spring抽象进行jdbc-trx管理。
SP方法有其优缺点：
Pro：
- 您可以定制特定于数据库的查询，a可能会获得优势性能
- 减少对第三方的依赖打火机分布
- 您是DBA
缺点：
- 您依赖于数据库
- 您的JUnit将需要与数据库交互
- 你需要一个DBA
无论如何，我会使用springJDBC模板，从我的角度来看，它是一个很好的JDBC抽象，可以为您节省样板代码和错误。
如果您选择java事务管理，我将添加Spring PlatformTransactionManager。
添加spring-jdbc和spring-tx-jar不会产生巨大的大小影响。这两个罐子大约有80万，我想还会添加一些额外的依赖罐子。