Hibernate中执行Transaction.commit()方法遇到错误

Hibernate事务异常解析
最新推荐文章于 2023-11-10 16:07:55 发布
原创 最新推荐文章于 2023-11-10 16:07:55 发布 · 2.9k 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#hibernate

本文分析了一个常见的Hibernate事务异常问题：TransactionException。详细解释了错误发生的原因在于同一个session中并发开启多个事务并尝试提交，提供了代码示例并指出了解决此类问题的方法。
每次都显示org.hibernate.TransactionException: Transaction not successfully started
看了下代码，查了下资料，原因是代码结构问题：
Transaction tx1 = session.beginTransaction();
Transaction tx2 = session.beginTransaction();
tx2.commit();
tx1.commit();
因为他们是指向的一下transaction, 所以当执行tx1.commit()时就报那个错。
eclipse学习（第三章：ssh中的Hibernate）——9.Hibernate里面的标准查询
weixin_43987277的博客
06-12 721
eclipse学习（第三章：ssh中的Hibernate）——8.Hibernate里面的查询语言（使用hql帮助开发）前言 前言 本文参考自https://www.w3cschool.cn/hibernate/ugov1ie8.html后做的一个实践日志记录。 旧版本的话，你直接这么使用是没有任何问题的。 但是如果你换了版本，这个hibernate版本是在Hibernate5.2之后就会出现了已弃用的标志，要改为如下情况。 ...
Hibernate配置文件hibernate.cfg.xml详解、实体.hbm.xml 映射文件详解-day02上
ShuYY的博客
08-26 978
目录第一节 Hibernate配置文件详解1.1 hibernate.cfg.xml详解1. 配置数据库连接的4个参数2. sql语句显示与sql格式化语句3. 自动提交事务与session本地线程绑定4. 配置映射文件与数据库表的关系5. hibernate.dialect 数据库方言6. 配置JavaBean与表的映射文件【常用】附 hibernate.cfg.xml1.2 hbm.xml 映射文件详解 第一节 Hibernate配置文件详解 1.1 hibernate.cfg.xml详解 1. 配置数
hibernate数据commit不成功
天将降大任于是人
09-25 4053
改程序的时候写了两个：transaction = session.beginTransaction();.....transaction = session.beginTransaction();导致transaction.commit()提交不成功
Java commit()_java – Hibernate中的transaction.commit()是什么？
weixin_31147757的博客
02-16 299
transaction.commit()做什么？Account account = new Account();account.setId(100);account = (Account) session.get(Account.class,account.getId());System.out.println("Before Transaction: Balance = " + account....
hibernate报数组越界的问题java.lang.ArrayIndexOutOfBoundsException: 0
越努力越幸运
02-16 892
1.挨个查看model层、service层、dao层，肯定有一个出错了！！！！！找了两天!!!!!!!!!!!!!!!!!
org.hibernate.TransactionException: commit failed
牛栏山矿泉水
11-05 878
1、错误描述 org.hibernate.TransactionException: commit failed at org.hibernate.engine.transaction.spi.AbstractTransactionImpl.commit(AbstractTransactionImpl.java:187) at filter.TranscationFilter.doFilte...
新Hibernate SessionFactory().getCurrentSession()猫腻
04-18
在Java世界中，Hibernate是一个非常流行的ORM（对象关系映射）框架，它使得开发者能够方便地将数据库操作与业务逻辑代码解耦。标题提到的"新Hibernate SessionFactory().getCurrentSession()猫腻"揭示了一个常见的...
Hibernate相关类包.zip_hibernate
09-21
例如，Session的`beginTransaction()`, `commit()`, `rollback()`方法用于控制事务的生命周期。 7. **二级缓存**：Hibernate的二级缓存可以提高性能，它存储了不同Session之间共享的数据。可以通过配置插件（如...
Hibernate_day01.zip
09-15
4. **Transaction管理**：通过`Session.beginTransaction()`开始事务，`transaction.commit()`提交事务，`transaction.rollback()`回滚事务，确保数据操作的原子性。 5. **Criteria API的子查询**：可以创建子查询...
transaction事务使用
yuanjianqiang_0925的博客
11-10 1805
需要注意的是，在多数编程语言和数据库中，事务必须在同一个数据库连接上使用，以确保事务中的所有操作都在同一会话下被处理。注意，在使用事务期间，应该遵循正确的异常处理和事务提交/回滚的方式，以确保事务的完整性和一致性。需要注意的是，事务的关闭操作应该放在合适的地方，例如在业务方法的最后一步进行关闭。事务的关闭是指事务执行完毕或者发生异常时，需要显式地进行事务的提交或回滚操作，以确保事务的完整性和一致性。事务的嵌套使用是指在一个事务的执行过程中，调用了另一个需要事务的方法。首先，确保你的代码中已经开启了事务。
FragmentTransaction commit 报错：java.lang.IllegalStateException: commit already called
ChinaDragon10的博客
06-24 919
程序代码如下图所示： 横竖屏切换时候，FragmentTransaction commit 报错：java.lang.IllegalStateException: commit already called 根据上面的错误信息继续追踪 BackStackRecord.java类里面的 commitInternal 方法 从上面图片源码可以看到FragmentTransaction 调用的commit时最终是调用commitInternal 方法，在commitInternal 里如果mCommitte
FragmentTransaction commit方法报错
zke1994的博客
07-30 1627
java.lang.IllegalStateException: Can not perform this action after onSaveInstanceState 不能在onSaveInstanceState的方法之后调用commit方法   原因: 由于commit方法可以在调用之前保存fragment回退状态, 所以当系统自动回调onSaveInstanceState此方法时表...
android开发使用fragment commit时的一些坑
hunan_lijie_的专栏
06-24 5866
今天在开发过程中，发现一个问题，花了将近两个小时才解决。现在我把问题描述一下。我有一个两个界面(Activity),在第一个activity中使用了几个tag页的样式，每个tag页对应一个fragment，我写了一个函数setChartSelector，专门用来进行切换tab页的，当点击某一个地方时，进入横屏的界面。横屏界面也有几个tag页，和第一个activity的tab是一样的。我们的需求是，
有关Transaction的错误提示及正确的处理（原创）
weixin_34021089的博客
06-28 3500
最近在写代码中处理事务的时候出现了几个问题，现在整理一下贴到网上。本文除特别指明外，均采用DAAB 3.1的Odbc类连接Sybase 9.1.2。 1.当分配给命令的连接处于挂起的本地事务中时，命令必须具有事务对象才能执行。该命令的 Transaction 属性尚未初始化。 问题出现的原因是Transaction并没有初始化。不过由于DAAB的Odbc类对ADO.Net的一些方法和类进行了封...
Spring接口方法加@Transactional失效的原因解析
GalenGao
04-19 4842
问题 今天项目测试一个方法的时候，发现日志报错，日志报错大致如下：Connection is read-only. Queries leading to data modification are not allowed org.springframework.dao.TransientDataAccessResourceException: ### Error updating database...
org.springframework.orm.ObjectOptimisticLockingFailureException: Batch update returned unexpected row count from update [0]; actual row count: 0; expected: 1; nested exception is org.hibernate.StaleStateException: Batch update returned unexpected row count from update [0]; actual row count: 0; expected: 1 at org.springframework.orm.jpa.vendor.HibernateJpaDialect.convertHibernateAccessException(HibernateJpaDialect.java:320) at org.springframework.orm.jpa.vendor.HibernateJpaDialect.translateExceptionIfPossible(HibernateJpaDialect.java:244) at org.springframework.orm.jpa.JpaTransactionManager.doCommit(JpaTransactionManager.java:521) at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:761) at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:730) at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:487) at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:291) at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:96) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179) at org.springframework.dao.support.PersistenceExceptionTranslationInterceptor.invoke(PersistenceExceptionTranslationInterceptor.java:136) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179) at org.springframework.data.jpa.repository.support.CrudMethodMetadataPostProcessor$CrudMethodMetadataPopulatingMethodInterceptor.invoke(CrudMethodMetadataPostProcessor.java:133) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:92) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:213) at com.sun.proxy.$Proxy566.deleteLiquidReportChartByDataDtAndReportCode(Unknown Source) at com.htsc.service.DebtBusinessDayReportService.generateReport(DebtBusinessDayReportService.java:81) at com.htsc.task.DebtBusinessDayReportJob.init(DebtBusinessDayReportJob.java:56) at com.htsc.task.DebtBusinessDayReportJob$$FastClassBySpringCGLIB$$6c4100a4.invoke(<generated>) at org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:204) at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:720) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:157) at org.springframework.aop.interceptor.AsyncExecutionInterceptor$1.call(AsyncExecutionInterceptor.java:115) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) Caused by: org.hibernate.StaleStateException: Batch update returned unexpected row count from update [0]; actual row count: 0; expected: 1 at org.hibernate.jdbc.Expectations$BasicExpectation.checkBatched(Expectations.java:67) at org.hibernate.jdbc.Expectations$BasicExpectation.verifyOutcome(Expectations.java:54) at org.hibernate.engine.jdbc.batch.internal.NonBatchingBatch.addToBatch(NonBatchingBatch.java:46) at org.hibernate.persister.entity.AbstractEntityPersister.delete(AbstractEntityPersister.java:3209) at org.hibernate.persister.entity.AbstractEntityPersister.delete(AbstractEntityPersister.java:3446) at org.hibernate.action.internal.EntityDeleteAction.execute(EntityDeleteAction.java:98) at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:582) at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:456) at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:337) at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:39) at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1282) at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:465) at org.hibernate.internal.SessionImpl.flushBeforeTransactionCompletion(SessionImpl.java:2963) at org.hibernate.internal.SessionImpl.beforeTransactionCompletion(SessionImpl.java:2339) at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.beforeTransactionCompletion(JdbcCoordinatorImpl.java:485) at org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorImpl.beforeCompletionCallback(JdbcResourceLocalTransactionCoordinatorImpl.java:147) at org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorImpl.access$100(JdbcResourceLocalTransactionCoordinatorImpl.java:38) at org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorImpl$TransactionDriverControlImpl.commit(JdbcResourceLocalTransactionCoordinatorImpl.java:231) at org.hibernate.engine.transaction.internal.TransactionImpl.commit(TransactionImpl.java:65) at org.hibernate.jpa.internal.TransactionImpl.commit(TransactionImpl.java:61) at org.springframework.orm.jpa.JpaTransactionManager.doCommit(JpaTransactionManager.java:517) ... 25 common frames omitted这是什么原因导致的
最新发布
11-11
这个异常： ``` org.springframework.orm.ObjectOptimisticLockingFailureException: Batch update returned unexpected row count from update [0]; actual row count: 0; expected: 1 Caused by: org.hibernate.StaleStateException: Batch update returned unexpected row count from update [0]; actual row count: 0; expected: 1 ``` 是 **乐观锁（Optimistic Locking）机制** 触发的典型错误，表示在尝试更新或删除数据库记录时，**预期影响了 1 行数据，但实际影响了 0 行**。 --- ### ✅ 异常原因分析 #### 核心问题： > **你要操作的数据在数据库中已经不存在了，或者版本不一致（version mismatch），导致 Hibernate 的乐观锁检查失败。** 具体场景如下： 1. ### 使用了 `@Version` 字段进行乐观锁控制 ```java @Entity public class LiquidReportChart { @Id private Long id; @Version private Integer version; // 乐观锁字段 // 其他字段... } ``` 2. 当你加载实体后，Hibernate 会记录其 `version` 值。 3. 在执行 `save()` / `delete()` 操作前，如果该实体已经被其他事务修改过（`version` 已经递增），那么当前事务持有的 `version` 就是旧的。 4. 此时再做 `update` 或 `delete`，Hibernate 会在 SQL 中加入条件： ```sql UPDATE liquid_report_chart SET ..., version = ? WHERE id = ? AND version = ? ``` 5. 如果没有匹配到任何行（比如数据已被删除，或 version 不符），数据库返回受影响行数为 0。 6. Hibernate 预期应影响 1 行，结果得到 0 → 抛出 `StaleStateException` → 转换为 `ObjectOptimisticLockingFailureException` --- ### 📌 常见触发场景 | 场景 | 描述 | |------|------| | 1. 数据已被并发修改 | 多个线程/请求同时操作同一实体，一个提交后另一个使用的是旧数据 | | 2. 实体已被删除 | 在调用 `delete()` 之前，数据已经被别的事务删掉了 | | 3. 手动设置错误的 ID 或 Version | 程序中伪造了一个不存在的 ID 或过期的 version 去执行更新 | | 4. 缓存中的脏数据 | 使用二级缓存或应用缓存，读到了过期对象 | --- ### 🔍 结合你的堆栈信息分析 从堆栈看关键方法是： ```java at com.htsc.service.DebtBusinessDayReportService.generateReport(DebtBusinessDayReportService.java:81) at com.htsc.task.DebtBusinessDayReportJob.init(DebtBusinessDayReportJob.java:56) ``` 说明你在定时任务中生成报表，并试图删除某个历史图表数据： ```java deleteLiquidReportChartByDataDtAndReportCode(...) ``` 可能流程是： 1. 查询某天某报表的数据是否存在； 2. 删除旧数据； 3. 插入新数据； 但如果多个实例运行、或上一次未完成就再次触发 → 可能出现“重复删除” → 第二次删除时数据已不存在 → 抛出此异常。 --- ### ✅ 解决方案 #### ✅ 方案一：捕获异常并优雅处理（推荐用于幂等操作） 如果你的操作是 **幂等的**（例如“确保某数据不存在”），可以直接忽略删除失败的情况。 ```java @Service public class DebtBusinessDayReportService { @Autowired private LiquidReportChartRepository repository; public void deleteSafely(String dataDt, String reportCode) { try { repository.deleteLiquidReportChartByDataDtAndReportCode(dataDt, reportCode); } catch (ObjectOptimisticLockingFailureException ex) { // 数据可能已被删除，无需处理 log.warn("Data already deleted for date={} and reportCode={}", dataDt, reportCode); } } public void generateReport(...) { deleteSafely(dataDt, reportCode); // 安全删除 // 再插入新数据... } } ``` --- #### ✅ 方案二：先查后删 + merge 判断是否存在 ```java public void deleteIfExists(String dataDt, String reportCode) { List<LiquidReportChart> charts = repository.findByDataDtAndReportCode(dataDt, reportCode); if (charts.isEmpty()) { log.info("No data found to delete for {} - {}", dataDt, reportCode); return; } repository.deleteAll(charts); } ``` 这种方式避免直接基于旧状态删除，适合无 `@Version` 控制的场景。 --- #### ✅ 方案三：关闭乐观锁（不推荐！仅特殊用途） 如果你确定不需要并发安全保护，可以移除 `@Version` 字段。但这会带来数据覆盖风险，**不建议在生产环境使用**。 --- #### ✅ 方案四：使用原生 SQL 删除，绕过实体管理 适用于只关心结果而不关心对象状态的场景： ```java @Modifying @Query(value = "DELETE FROM liquid_report_chart WHERE data_dt = :dataDt AND report_code = :reportCode", nativeQuery = true) int deleteByDataDtAndReportCode(@Param("dataDt") String dataDt, @Param("reportCode") String reportCode); ``` 注意返回值是 `int` 影响行数，你可以判断是否删除成功： ```java int rows = repo.deleteByDataDtAndReportCode(...); if (rows == 0) { log.info("No rows were deleted, possibly already gone."); } ``` 这种方式不会抛出乐观锁异常，因为没走实体版本校验逻辑。 --- ### 🧪 如何复现这个问题？ - 启动两个线程： - Thread A 加载实体（version=1） - Thread B 更新实体（version→2） - Thread A 提交更改 → 失败！ --- ### ✅ 最佳实践建议 | 措施 | 说明 | |------|------| | ✅ 对写操作添加异常处理 | 特别是涉及乐观锁的更新/删除 | | ✅ 使用业务主键查询代替盲目操作 | 减少对持久化上下文的依赖 | | ✅ 幂等设计 | “删除不存在的数据”不应报错 | | ✅ 日志记录 | 记录何时发生 stale state，便于排查 | | ✅ 分布式环境下加分布式锁 | 如 Redis 锁防止重复执行定时任务 | --- ###
评论 1
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值