回滚

No transaction aspect - managed TransactionStatus in scope 出现该异常的原因是因为 在主方法A 中调用了其他模块接口B，然而在B接口 没有声明事务 但是手动回滚了 TransactionAspectSupport . currentTransactionStatus ( ) . setRollbackOnly ( ) ; //回滚 然而在主方法A中却声明了事务，B 接口出错之后 ， A方法进行事务回滚是就会出现该异常， 来源：51CTO 作者： weixin_41336805 链接：https://blog.csdn.net/weixin_41336805/article/details/100053095

/*--> */ /*--> */ RenGuoQiang@PC-RENGUOQIANG MINGW64 /d/zgg/zgg-crm (master) $ git reset --hard 194e2cc8eec88743cc89783d9003663e47cc44ab HEAD is now at 194e2cc8 fixbug: 调整查询条件样式 (补充) RenGuoQiang@PC-RENGUOQIANG MINGW64 /d/zgg/zgg-crm (master) $ git push -f -u origin master Total 0 (delta 0), reused 0 (delta 0) To https://git.zhiguagua.com/zgg-crm.git + 2bd0541e...194e2cc8 master -> master (forced update) Branch 'master' set up to track remote branch 'master' from 'origin'. 来源： https://www.cnblogs.com/rgqancy/p/11756730.html

1、遇到的问题 当我们一个方法里面有多个数据库保存操作的时候，中间的数据库操作发生的错误。伪代码如下： public method() { Dao1.save(Person1); Dao1.save(Person2); Dao1.save(Person2);//假如这句发生了错误，前面的两个对象会被保存到数据库中 Dao1.save(Person2); } 期待的情况：发生错误之前的 所有数据库保存操作都回滚 ，即不保存 正常情况：前面的数据库操作会被执行，而发生数据库操作错误开始及之后的所有的数据保存操作都将失败。这样子应该都不是我们要的结果吧。 当遇到这种情况，我们就可以使用Spring的事务解决这个问题。 2、异常的一些基本知识 异常的架构 异常的继承结构：Throwable为基类，Error和Exception继承Throwable，RuntimeException和IOException等继承Exception。Error和RuntimeException及其子类成为未检查异常（unchecked），其它异常成为已检查异常（checked）。 2）Error异常 Error表示程序在运行期间出现了十分严重、不可恢复的错误，在这种情况下应用程序只能中止运行，例如JAVA 虚拟机出现错误。Error是一种unchecked Exception

版权声明：该文章仅作为个人记录分享，若有其他用途请注明出处。 【JCccc】 https://blog.csdn.net/qq_35387940/article/details/91494169 事务控制一般在一些比较重要的业务都需要考虑。 进入正题，关于事务Transactional 的要点以及使用方式： @Transactional 1.需要将使用事务注解的方法设置为public； 2.如果没有在注解后做异常配置，只会对手动抛出的 throw new RuntimeException() 起作用； 3.若想对其余异常起作用，则需做类似配置 @Transactional(rollbackOn = Exception.class) ； 4.手动回滚，在使用注解后，在需要执行事务回滚的地方，TransactionAspectSupport.currentTransactionStatus().setRollbackOnly(); （使用手动回滚，就不需要抛异常了） 很多时候往往抛出异常进行回滚后无法return或者做一些其余的逻辑，那么这种情况使用手动事务回滚是非常不错的。 转载请标明出处: Springboot 快速了解 事务回滚@Transactional 文章来源: https://blog.csdn.net/qq_35387940/article/details

用途 数据快速回滚(闪回) 主从切换后新master丢数据的修复 从binlog生成标准SQL，带来的衍生功能 安装 git clone https://github.com/danfengcao/binlog2sql.git && cd binlog2sql pip install -r requirements.txt mysql参数设置 [mysqld] server_id = 1 log_bin = /var/log/mysql/mysql-bin.log max_binlog_size = 1G binlog_format = row binlog_row_image = full 对用户赋权 GRANT SELECT, REPLICATION SLAVE, REPLICATION CLIENT ON . TO ‘glon’@’%’ IDENTIFIED BY ‘glon’ 通过模糊时间点解析binlog python binlog2sql/binlog2sql.py -h127.0.0.1 -P3306 -uglon -p’glon’ -d test -t tb1 --start-file=‘mysql-bin.000052’ --start-datetime=‘2016-12-13 20:25:00’ --stop-datetime=‘2016-12-13 20:30

地址 Rank Solved A B C D E F G H I J 51/384 4/10 . . . O O . O . O O : 当场通过 : 赛后通过 . : 尚未通过 A Domains unsolved B K-Dimensional Foil unsolved C Graph upsolved by chelly chelly's solution 很显然的思路就是莫队+并查集 但众所周知并查集可以支持可撤销，但不是很好支持可持久化 于是就可以用上回滚莫队的套路了，回滚莫队可以把一般莫队的删除操作变成撤销操作，复杂度不改变 于是这题用回滚莫队+可撤销并查集即可解决 注意回滚莫队的时候，处理右半边的点的时候，不能连向左半边的点，否则rollback的时候跨越中间的边并没有撤销 D Chinese Checkers unsolved E Cats and Fish solved by chelly chelly's solution F Secret Poems solved by chelly chelly's solution G Liaoning Ship’s Voyage unsolved H Puzzle Game solved by chelly chelly's solution I Colored Nodes unsolved J Pangu and

群里经常卧虎藏龙，转载一篇百度大牛，投稿原创文章，大家交流学习 ，欢迎更多朋友投稿，发布原创文章和干货和大家分享交流。 引言 在互联网系统中，理想的情况下，肯定是希望系统能够同时满足“一致性”、“可用性”和“分区容忍性”。 但是基于熟悉的CAP定律也好，还是BASE理论， 我们知道，在实际情况中是不可能实现的。而在金融领域，一致性是最为关注的特性，任何情况下都必须满足一致性。关于CAP定律和BASE理论，本文不再介绍，有兴趣的同学可以自行百度一下。本文重点来阐述下关于一致性的方案，包括强一致性和最终一致性。 而在互联网领域， 很多情况下都是牺牲强一致性，来达到高可用性， ϵ 统往往只需要保证“最终一致性”，只要这个最终时间是在用户可以接受的范围内即可。 数据库本地事务 数据库事务肯定是强一致性的方案，而且是一致性最简单的方案，因为一致性是数据库的事务来保证的，业务层不需要关心细节。比较典型的应用是在返现场景下，针对带有返现的交易的退款，需要一次性退两笔交易单，采用的就是通过数据库本地事务来完成的。具体如下： 用户A花了100元购买商户B的商品，购买结束后返现给用户A 2元。 这是两笔交易，原始交易是100元，返现交易是2元。 那么发生退款时，需要保证两笔交易同时都退款。这个就是直接采用数据库本地事务实现的，即一次退款请求，两笔交易同时退款。 总结： 数据库事务的优点是简单

2019独角兽企业重金招聘Python工程师标准>>> java . sql . SQLException : Can ' t call commit when autocommit=true at com.mysql.jdbc.SQLError.createSQLException(SQLError.java: 934 ) at com.mysql.jdbc.SQLError.createSQLException(SQLError.java: 931 ) at com.mysql.jdbc.ConnectionImpl.commit(ConnectionImpl.java: 1646 ) 　　今天遇到这个问题，使用hibernate的时候报上面的错！ 　　上网查了下原因，是因为hibernate中使用了,commit()或者rollback(),这两个都需要一个先决条件，就是mysql的自动提交功能要关闭。 　　commit()的作用是：提交上一次提交或者回滚后的修改的内容，并释放连接中的相关内容。 　　rollback()的作用是：回滚到上一次提交或者回滚时的内容。 　　上面两个方法都只能在已禁用自动提交的模式中使用。 　　因此， 关闭mysql自动提交 就可以了。 　　在mysql客户端中： 　　 mysql > select @ @autocommit ; 　

事务是访问并更新数据库中各个数据项的一个程序执行单元。在事务操作中，要不都做修改，要么都不做。 事务具有ACID四个特性，分别是：原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability)。 原子性是指要么不做，要么都做。 原子性是指数据库中不可分割的工作单位，只有使事务中所有的数据库操作都执行成功，才算整个事务成功。 事务中任何一个SQL语句执行失败，已经执行成功的SQL语句必须撤销，数据库状态应该退回到执行事务前的状态。 是指数据库从一种状态转变为下一种一致的状态，具体来说就是在事务开始前和事务结束以后，数据库的完整性约束没有被破坏。 事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。 重做日志 与原子性一样，事务的持久性也是通过日志来实现的，MySQL 使用重做日志（redo log）实现事务的持久性，重做日志由两部分组成，一是内存中的重做日志缓冲区，因为重做日志缓冲区在内存中，所以它是易失的，另一个就是在磁盘上的重做日志文件，它是持久的。 当我们在一个事务中尝试对数据进行修改时，它会先将数据从磁盘读入内存，并更新内存中缓存的数据，然后生成一条重做日志并写入重做日志缓存，当事务真正提交时，MySQL 会将重做日志缓存中的内容刷新到重做日志文件，再将内存中的数据更新到磁盘上，图中的第 4、5

No.1　　自动化部署git项目 һһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһһ #!/bin/bash # 清除项目进程和历史文件 pkill -f start.py sleep 1 cd /root/automation |rm -rf testProduce/ # 获取项目最新git代码（前提服务器配置好git账户） git clone git@dev.test.com:test_code/testProduce.git # 启动项目 cd testProduce/ nohup /usr/python/bin/python3 start.py & sleep 3 # 检查是否启动成功 pinfo=`pgrep -af start.py` if [ -n $pinfo ] then echo "Successfully!!!" else echo "Failed!!!" fi No.2　　自动化更新git项目