返回信息流回滚除了回滚已经操作过的数据外还有回滚待执行的语句，因为hibernate的jdbc事务出错后是不会去commit转而执行回滚，这个回滚就是回滚flush到数据库中的语句。
这是一条镜像帖。来源：北邮人论坛 / database / #6437同步于 2012/4/14
该镜像源已超过 30 天没有更新，可能在源站已被删除。
Database机器人发帖
Re: hibernate jdbc 事务的回滚的作用？
OK608
2012/4/14镜像同步5 回复
订阅后，新回复会通过你的通知中心匿名送达。
5 条回复
hbm提交前出错，那么数据库为什么是一致的？不一定吧，因为事务是由你定义的，这个事务包含哪些操作是由你说了算，既然定义在一个事务中，那只有全部执行完才能是业务性质的一致。
我知道oracle数据库不会自动commit和rollback，在一个包含多个操作的事务中只会将出错的语句rollback，已经执行过的不会自动commit或者rollback。
发出rollback后，就是回滚所有的操作，从撤销段中恢复数据
我的理解是hbm提交是在最后执行，无论是提交前的错误或者是提交成功前的错误导致的回滚是清除前面数据库操作的所产生的脏数据，一般数据库有四个级别的事务隔离有一个就是TRANSACTION_READ_UNCOMMITTED，这个是能在数据库中看到还未最终提交的数据，其实提交前的操作已经对数据库产生的影响，但是为了事务的完成性而不能被其他事务使用，我们也看不到数据的修改，回滚都是在真正的提交之前发生，真的提交了，undo表的数据是会被覆盖的，是不能回滚了。请指教
lz我的理解是这样的。实际上数据库在进行保存操作的时候，会有相关的日志生成，包括undo页和备份在临时表上的页得副本。执行rollback不仅仅是回滚保存到磁盘上的数据，也许还需要对相关的其他操作进行回滚和日志的记录。这是我这几天查资料的想法。不知道对不对，我会继续就这个问题跟进的
【 在 OK608 的大作中提到: 】
: 我的理解是hbm提交是在最后执行，无论是提交前的错误或者是提交成功前的错误导致的回滚是清除前面数据库操作的所产生的脏数据，一般数据库有四个级别的事务隔离有一个就是TRANSACTION_READ_UNCOMMITTED，这个是能在数据库中看到还未最终提交的数据，其实提交前的操作已经对数据库产生的影响，但是为了事务的完成性而不能被其他事务使用，我们也看不到数据的修改，回滚都是在真正的提交之前发生，真的提交了，undo表的数据是会被覆盖的，是不能回滚了。请指教
lz是在这样的，MySQL数据库默认事务是自动提交的，但是在应用程序中显式使用事务的时候，会在事务开始前将自动提交设置为由程序控制进行提交。在进行commit的时候，实际上是将redo的事务日志刷到磁盘上，同时数据也会被一起从内存页刷新到磁盘上保存，如果此时出现错误，MySQL是不会自动执行回滚的。此时事务已经把部分数据保存到磁盘上了。这个状态处于数据不一致的状态。此时显式调用rollback才会把前面已经成功保存到磁盘上的数据回滚并且参照undo的信息将数据库状态真正回滚到事务开始的时候。这是我的理解。希望能得到您的批评指正
谢谢你的关注，我也是调用hibernate时产生的疑惑，但是并没有做深入的实践了解，我也是搜了网上的一些文章但是不能满意，我觉得你说的很有道理，有时间的话写段代码验证下，共勉励。
【 在 zhihao 的大作中提到: 】
:
: lz是在这样的，MySQL数据库默认事务是自动提交的，但是在应用程序中显式使用事务的时候，会在事务开始前将自动提交设置为由程序控制进行提交。在进行commit的时候，实际上是将redo的事务日志刷到磁盘上，同时数据也会被一起从内存页刷新到磁盘上保存，如果此时出现错误，MySQL是不会自动执行回滚的。此时事务已经把部分数据保存到磁盘上了。这个状态处于数据不一致的状态。此时显式调用rollback才会把前面已经成功保存到磁盘上的数据回滚并且参照undo的信息将数据库状态真正回滚到事务开始的时候。这是我的理解。希望能得到您的批评指正