Spring事务管理方案-AOP和@Transactional
嗯，在这个问题上我可能是错的，但是我需要你的宝贵意见/建议来站在正确的道路上。
我想知道在SpringHibernate和SpringJDBCTemplate中处理事务管理的好的、更好的、最好的方法，以及每种方法的优缺点。
我知道的一些方案/方法也是如此：
1） 使用AOP注释的Spring事务管理（@Aspect，@PointCut，带有诸如@Before，@After，@Around等建议）。
问题1：我之前用SpringAOP做了一个日志示例，但我不知道如何在事务管理中做同样的事情。事务是否会在该方面类中启动、回滚和提交，并提供类似于@Before、@Before、@After、@Around？请为此共享一些代码示例/代码片段。
问题2：这种方法是强烈要求Hibernate事务管理器，还是可以在没有它的情况下实现？
2）带有@Transactional注释的Spring事务管理器：另一种事务管理方案，涉及Hibernate事务管理器，用于带有@Transactional注释的声明性事务管理。
问题-3：在方法上使用@Transactional注释可以保证该方法主体中的所有事务管理，但是在该特定方法中的不同实体上的多DAO操作中，您将如何以这种方式管理回滚功能？比如说，您正在该方法中执行3-4个不同的DAO操作（在带有@Transactional的不同DAO方法上），并且在第3个DAO操作中出现一些异常，您将如何回滚。
请分享你的观点！
祝好
阿伦
共有1个答案
我认为您应该使用选项2（例如Spring事务管理工具），因为它已经被实现和测试：）。关于“问题3”：这取决于您为所有“事务性”DAOAPI选择的传播策略。请检查javadoc@Transactional和“传播”部分。希望这有帮助。
-
我创建了一个包含@Transactional注释的方面。正在按预期调用我的建议，但新实体AuditRecord从未保存到数据库中，看起来我的@Transactional注释不起作用。 bean上下文如下： 我的切入点是只拦截接口（服务接口）。服务方法可能是也可能不是事务性的。如果服务方法是事务性的，如果建议因某种原因失败，我希望该事务被回滚。 我的问题是：为什么要忽略事务注释？这是我第一次用Spr
-
在我的spring服务中，我调用了两个spring数据存储库方法 现在我的查询与事务管理相关。就我所了解和看到的代码而言，spring存储库使用@Transactional为其方法启用了事务。对于select操作，它的readonly=true。 我对事务的理解是，当执行选择操作时，会创建一个事务，然后为保存操作创建另一个事务，因为对于选择操作，事务只读=true。 我希望在单个事务中执行读写操作
-
问题内容： 我刚刚开始使用spring和hibernate进行项目。我的DAO图层类扩展了HibernateDaoSupport。我们没有使用注释。之前，我们使用了struts，因此我们使用了Session类提供的getTransaction，commit，rollback ..方法。我的要求非常简单，对于所有DAO类，如果有异常，则回滚，否则提交。请提出介绍spring交易管理的最简单方法。 问
-
问题内容： 我正在使用Callable接口在serviceImpl中编写多线程程序。我正在使用spring事务管理器。在DB中执行更新操作时，它会成功执行。但是更新后的数据不会反映在DB中。但是，当我运行不带多线程的程序时，它将在DB中更新。 这是我的配置 我可以转向事务管理器的另一种方法。只是我想确认这种方法是否支持多线程。所以我的问题是 spring事务管理器是否支持多线程（我的意思是仅通过声
-
我试图将Spring引导指南中的管理事务示例扩展到两个数据源，但是@事务注释似乎只适用于其中一个数据源。 在"Application.java"中，我添加了两个数据源及其Jdbc模板的bean。在"BookingService.java"中，我使用了属于第二个数据源的JdbcTemboard。 这是我的“Application.java”： 下面是“BookingService.java”： 这些
-
管理交易 在 1.4 版更改: 对会话事务管理进行了修改，使其更清晰、更易于使用。特别是，它现在具有“autobegin”操作的特点，这意味着事务开始的点可以被控制，而不必使用传统的“autocommit”模式。 这个 Session 一次跟踪单个“虚拟”事务的状态，使用一个名为 SessionTransaction 。然后，该对象利用基础的 Engine 或引擎，而这些引擎 Session 对象