回滚

Spring boot是默认启动事务的，只需要在类或者方法上添加@Transactional注解即可，但有时候会发现事务不生效，具体原因可以从以下几个方面找寻： 1、 首先要看数据库引擎是否支持注解，mysql默认引擎INNODB是支持的 ， 但MYISAM是不支持的 ； 2、 注解只能被应用到public方法上, 其它方法上不会报错，但不生效； 3、 默认情况下只会对运行期异常(java.lang.RuntimeException及其子类)和 Error 进行回滚 ； 4、 如果是其它异常，可以显形标记在参数里，下图标红的就是先进行查看用户有指定的异常，如果没有，就默认上一条的异常，参数格式：@Transactional(rollbackFor={Exception.class}) 5、 是否进行了异常捕获，如果使用了try–catch，事务是肯定不生效，也就是系统没有接收到异常场景； 关于使用异常捕获，还想事务生效，可以有几种策略解决相关难题： 5.1、手动回滚 5.2、在catch里抛出一个runntimeException 5.3、将异常写入注解参数里面，也需要抛出来，原理跟方法2一样的，只是重新指定了事务回滚的异常类型 隔离级别 . Mysql默认采用 REPEATABLE_READ 隔离级别 Oracle默认采用 READ_COMMITTED 隔离级别 来源： CSDN

原文: 监控SQL：执行表中所有sql语句、记录每个语句运行时间(3) 通过执行一个 带参数的存储过程 exec OpreateTB('OpreateUser','IsRun') 更新表的数据 表结构：（RunTime，RunStatus,BetweenTime,RunLog,IsRun）。 字段解释： 1、RunTime 这条语句的执行时间 2、RunStatus 为执行语句是否成功 1表示执行成功 0 表示异常 NULL 就是还未执行 -1表示回滚 3、BetweenTime ：执行这条语句所用时间 4、RunLog 执行 返回的消息结果 如（1行影响） 5、IsRun ：是否执行语句 0 表示 未执行,1表示已执行 执行过程如果有错误语句直接回滚 并且 Runlog 都更新为'回滚'。 执行 按照 OrderNumber 升序执行语句。 --delete from tb_CMd CREATE TABLE [dbo].[TB_CMD]( [RowGuid] [nvarchar](50) NOT NULL, [RunTime] [date] NULL, [RunStatus] [int] NULL, [SqlEvent] [nvarchar](max) NULL, [OrderNumber] [int] NULL, [IsRun] [bit] NULL, [OpreateUser

原文: 论坛中的问题：47(等待类型为MSSEARCH的进程被KILL之后，一直处于回滚状态) 求助：等待类型为MSSEARCH的进程被KILL之后，一直处于回滚状态 http://bbs.csdn.net/topics/391834154 等待类型 ： MSSEARCH SQL server 2005 我KILL了一个等待类型为MSSEARCH的进程，然后KILL之后sys.sysprocesses 表里面的status=runnable ，cmd=KILLED/ROLLBACK 。 要命的是再一次KILL这个进程的时候会提示：“SPID 126: 正在进行事务回滚。估计回滚已完成: 0%。估计剩余时间: 0 秒。” 这个回滚持续了三天了，要命的是这个SPID对应的查询里面涉及的表无法做rebuild index 。 MSSEARCH--官方解释：在全文搜索调用期间出现。该等待在全文操作完成时结束。它不指示争用，而指示全文操作的持续时间。 dbcc inputbuffer(126) 查看此进程执行的SQL就是一个普通的.net端传过来的select 。 请嫑让我重启服务，伤不起。 哪位大神遇到过这个恶心的问题，请不吝赐教。 最后回复一下我的解决方案吧： 0.和业务方沟通预估可能影响的业务范围和时间 1.禁用表上的全文索引 2.停掉全文索引服务 3

在日常使用GIT过程中，经常会出错，比如无意间丢失了未提交的数据，回退版本时丢失了工作目录，等等。经过思考发现，所有这些错误都是因为对GIT中一些基本的概念模糊而导致，因为对一些基本概念不清晰，导致对GIT每一条命令将会产生的结果不符合预期。下面我就梳理以下我经常碰到的问题相关的基本概念。 1. Working Directory（工作目录） Git的工作目录是保存当前正在工作的文件所在的目录，和working tree是相同的意思。在这个目录中的文件可能会在切换branch时被GIT删除或者替换。这个目录是个临时目录，临时存储你从GIT库中取出的文件，这些文件一直会被保存，直到下次提交。 2. GIT Directory（GIT库目录） 项目的所有历史提交都被保存在了GIT库目录中，只要你不作回滚操作，它应该不会丢失。 3. GIT Index（Git索引） Git index 可以看作是工作目录和Git库目录之间的暂存区，和staging area是相同的意思。可以使用Git index构建一组你准备一起提交的改变。Git Index和Git Staging area是同一个意思，都是指已经被add的但尚未commit的那些内容所在的区域。最简单的查看目前什么内容在index中的方法是使用 git status 命令。 命令中”Changes to be committed

目的：用rc在滚动升级之后，会造成服务访问中孤单，于是k8s引入了deploymentziyuan 创建deployment vim k8s_deploy.yml apiVersion: extensions/v1beta1 kind: Deployment metadata: name: nginx-deployment spec: replicas: 3 template: metadata: labels: app: nginx spec: containers: - name: nginx image: 10.0.0.11:5000/nginx:1.13 ports: - containerPort: 80 resources: limits: cpu: 100m requests: cpu: 100m 创建 kubectl create -f k8s_deploy.yml deployment升级和回滚 命令行创建deployment kubectl run nginx --image=10.0.0.11:5000/nginx:1.13 --replicas=3 --record 命令行升级版本 kubectl set image deploy nginx nginx=10.0.0.11:5000/nginx:1.15 查看deployment所有历史版本 kubectl

Outline 1.ACID 2.CAP 3.BASE 4.一致性协议 一直都对数据库事务不甚清楚，趁着前段时间对数据库事务级别进行了总结，一起对分布式事务进行总结梳理 ACID 1234 start transaction;update account set money = money-100 where userId = 1;update account set money = money+100 where userId = 2;commit; A（Atomicity），原子性 ，一个事务内的操作，要么全成功执行，要么全部不执行。 C（Consistency），一致性 ，事务执行的结果必须使将数据库从一种一致的状态变为另一种一致的状态，不可能出现中间状态，只有事务提交前状态和提交后状态，不存在提交中的状态。 I（Isolation），隔离性 ，每个读写事务的对象对其他事务的操作对象相互独立，即该事务提交前对其他事务都不可见。 D（Durability），持久性 ，一个事务一旦提交，它对数据库中对应数据的状态变更就是永久性的。 CAP 单机事务很容易实现支持ACID特性的事务处理系统，但是在分布式环境中问题就变得困难许多。 CAP理论告诉我们，一个分布式系统不可能同时满足一致性(C:Consistency)、可用性(A:Availability)、分区容错性(P

经过查询是因为在4.0版本之后新推出的数据引擎InnoDB与MyIASM之间的差别，改为MyIASM即可具体介绍参照。 插入数据的时候发现一切正常， 但数据并未插入数据库，甚是奇怪，后来发现在数据库中主键一直在增加，也就是说数据已经提交到数据库，主键自增以后并未插入。后来将表结构从InnoDB改为了MyIASM就可以了。查了一下Mysql的7种表结构，描述如下： DBD Berkeley DB(DBD)表是支持事务处理的表，由Sleepycat软件公司开发。它提供MySQL用户期待已久的功能事务控制。事务控制在任何数据库系统中都是一个极有价值的功能，因为它们确保一组命令能成功地执行或回滚。 HEAP HEAP表是MySQL中存取数据最快的表。这是因为他们使用存储在动态内存中的一个散列索引，不过如果MySQL或服务器崩溃，这些内存数据将会丢失。 ISAM ISAM表是早期MySQL版本的缺省表类型，直到MyIASM开发出来。建议不要再使用它。 MERGE MERGE是一个有趣的新类型，在3.23.25之后出现。一个MERGE表实际上是又一个MyISAM表的集合，合并而成的一个表，主要是为了效率的考虑，因为这样不仅仅可以提高速度、搜索效率、修复效率而且还节省了磁盘空间。 MyIASM MyIASM基于了IASM代码，应该可以说是IASM的衍生品，不过增加了不少有用的扩展

1.问题出现 1.代码如下： @Override @Transactional public void addUser2 ( String name , String password ) { userNoteMapper . addUser ( name , password ) ; System . out . println ( 1 / 0 ) ; } 2.现象是： 事务无论怎么样，都不进行事务的回滚，数据正常插入 3.问题排查： 1.首先进行方法的模拟，在dao测试，service测试，controller测试，接口测试，添加事务对插入无任何影响。排除在外？？？ 2.检查是否是类方法中的调用，只是单一的调用。排除在外？？？ 3.检查是否是数据库表的设计，mysql中引擎是否支持事务。在mysql中，innerdb是支持事务，而myisam不支持事务。我的错误正是数据表的引擎为myisam。 2.模拟spring事务的各种现象 1.李子 @Override @Transactional public void addUser2 ( String name , String password ) { userNoteMapper . addUser ( name , password ) ; System . out . println ( 1 / 0 ) ; //此处抛出异常

一、springMVC工作原理： 1.spring mvc请所有的请求都提交给DispatcherServlet,它会委托应用系统的其他模块负责负责对请求进行真正的处理工作。 2.DispatcherServlet查询一个或多个HandlerMapping,找到处理请求的Controller. 3.DispatcherServlet请请求提交到目标Controller 4.Controller进行业务逻辑处理后，会返回一个ModelAndView 5.Dispathcher查询一个或多个ViewResolver视图解析器,找到ModelAndView对象指定的视图对象 6.视图对象负责渲染返回给客户端。 二、 为什么要用 spring 三、 介绍一下 Spring 的事务管理 事务就是对一系列的数据库操作（比如插入多条数据）进行统一的提交或回滚操作，如果插入成功，那么一起成功，如果中间有一条出现异常，那么回滚之前的所有操作。 这样可以防止出现脏数据，防止数据库数据出现问题。 开发中为了避免这种情况一般都会进行事务管理。Spring中也有自己的事务管理机制，一般是使用TransactionMananger进行管理，可以通过Spring的注入来完成此功能。 sping的事务管理的两种方式： 1、编程式（粒度是到代码块级别）； 编程式主要使用transactionTemplate

安装git linux系统安装 sudo yum install git 如果是基于Debian的发行版，即Ubuntu系统 sudo apt-get install git mac系统安装 mac一般自带git 如果没有可到git官网进行下载： 点击跳转官网下载安装包 直接下一步就可以。。。安装完成后，打开终端，输入git --version，即可显示版本。表示安装成功。 windows系统安装 到git官网进行下载： 点击跳转官网下载安装包 直接下一步，可选择安装盘符。。。 安装完成后，点击右键会有Git Bash Here，点击后弹出命令行窗口，输入git --version，即可显示版本。表示安装成功。 git仓库的划分 Workspace：工作区，就是你在电脑里能看到的目录。 Index / Stage：暂存区，一般存放在 ".git目录下" 下的index文件（.git/index）中，所以我们把暂存区有时也叫作索引（index）。通过add命令将工作区内容添加到暂存区。 .git是我们初始化目录时git自动创建的一个隐藏目录，里面存放的是我们所有的版本信息。勿动！！！ Repository：仓库区（或本地仓库），工作区有一个隐藏目录.git。通过commit命令将暂存区内容添加到仓库区。 Remote：远程仓库。通过push命令将暂存区的内容提交到远程仓库。