事务管理

事务四大特性 原子性：不可分割的操作单元，事务中所有操作，要么全部成功；要么撤回到执行事务之前的状态 一致性：如果在执行事务之前数据库是一致的，那么在执行事务之后数据库也还是一致的； 隔离性：事务操作之间彼此独立和透明互不影响。事务独立运行。这通常使用锁来实现。一个事务处理后的结果，影响了其他事务，那么其他事务会撤回。事务的100%隔离，需要牺牲速度。 持久性：事务一旦提交，其结果就是永久的。即便发生系统故障，也能恢复。 MySQL的事务隔离级别 未提交读(Read Uncommitted)：允许脏读，其他事务只要修改了数据，即使未提交，本事务也能看到修改后的数据值。也就是可能读取到其他会话中未提交事务修改的数据 提交读(Read Committed)：只能读取到已经提交的数据。Oracle等多数数据库默认都是该级别 (不重复读)。 可重复读(Repeated Read)：可重复读。无论其他事务是否修改并提交了数据，在这个事务中看到的数据值始终不受其他事务影响。 串行读(Serializable)：完全串行化的读，每次读都需要获得表级共享锁，读写相互都会阻塞 MySQL数据库(InnoDB引擎)默认使用可重复读（ Repeatable read) 索引 数据库索引，是数据库管理系统中一个排序的数据结构，以协助快速查询、更新数据库表中数据。索引的实现通常使用 B_TREE。B

一个数据库可能拥有多个访问客户端，这些客户端并发访问数据库时，若没有采取必要的隔离措施，存在以下问题，这些问题分为5类，包括3类数据读问题：脏读、不可重复读和幻读。两类数据更新问题：第一类丢失更新、第二类丢失更新。 1.脏读 2.不可重复读 不可重复读是指A事务读取了B事务已经提交的 更改数据 。假如A在取款事务的过程中，B往该账户转账100，A两次读取的余额发生不一致。 3.幻读 A事务读取B事务提交的 新增数据 注意：不可重复读和幻读的区别是： 前者是指读到了已经提交的事务的更改数据（修改或删除），后者是指读到了其他已经提交事务的新增数据。 对于这两种问题解决采用不同的办法，防止读到更改数据，只需对操作的数据添加行级锁，防止操作中的数据发生变化；二防止读到新增数据，往往需要添加表级锁，将整张表锁定，防止新增数据（oracle采用多版本数据的方式实现）。 4.第一类丢失更新 这时候取款事务A撤销事务，余额恢复为1000，这就丢失了更新。 5.第二类丢失更新 为了解决上述问题，数据库通过 锁机制 解决并发访问的问题。根据锁定对象不同：分为行级锁和表级锁；根据并发事务锁定的关系上看：分为共享锁定和独占锁定，共享锁定会防止独占锁定但允许其他的共享锁定。而独占锁定既防止共享锁定也防止其他独占锁定。为了更改数据，数据库必须在进行更改的行上施加行独占锁定，insert、update

Innodb存储引擎 一次写入操作是一次事务，innodb 首先把事务数据写入到缓存池 Buffer Pool 和重做日志redo log中，然后就可以提交事务，响应客户端了。之后 innodb 再将新事务的数据异步地写入磁盘，真正存储起来。 Innodb主要是通过事务日志实现ACID特性 事务日志包括：重做日志redo和回滚日志undo Redo记录的是已经全部完成的事务，就是执行了提交的事务，记录文件是ib_logfile0 ib_logfile1 Undo记录的是已部分完成并且写入硬盘的未完成的事务，默认情况下回滚日志是记录下表空间中的（共享表空间或者独享表空间） 一般情况下，mysql在崩溃之后，重启服务，innodb通过回滚日志undo将所有已完成并写入磁盘的未完成事务进行回滚，然后redo中的事务全部重新执行一遍即可恢复数据，但是随着redo的量增加，每次从redo的第一条开始恢复就会浪费长的时间，所以引入了checkpoint机制 1.缓存池 buffer pool 数据的读写需要经过缓存（缓存在buffer pool 即在内存中） 数据以整页（16K）位单位读取到缓存中 缓存中的数据以LRU策略换出（最少使用策略） IO效率高，性能好（不用IO） 读操作： 数据是以页为存储单位，在缓冲池中缓存了很多数据页，当第一次读取时首先将页从磁盘读取到缓存池中

事务处理和并发控制 一、事务管理简介 1、事务含义 2、事务的属性ACID 四大属性：原子性、一致性、隔离性、持久性。 3、事务块管理的常用语句 BEGIN 和COMMIT同时用，是用来标识事务的开始和结束。 4、案例 ①、创建表 ②、插入数据并查询 二、事务并发控制 数据库中的数据并发操作经常发生，会出现： 1、脏读 2、幻读 3、不可重复性读取 三、锁机制 需要使用锁机制来保证事务的并发。使用锁可以解决用户存取数据的这个问题，从而保证数据库的完整性和一致性。 （一）、锁的类型 1、SpinLock (自旋锁) 2、LWLock (轻量级锁) 3、RegularLock 是一般数据库事务管理中所指的锁。只要特点是等待队列、死锁检测和能自动释放锁。 （二）、死锁 1、死锁出现的原因 行程死锁的必要条件： 2、可能会造成死锁的原因 ①、锁：等待获取资源（如对象、页、行、元数据和应用程序）的锁可能导致死锁。 ②、工作线程：排队等待可用工作线程的任务可能导致死锁。如果排队等待的任务拥有阻塞所有工作线程的资源，则将导致死锁。 ③、内存：当并发请求等待获得内存，而当前的可用内存无法满足其需求时、可能发生死锁。 ④、并行查询的相关资源。通常与交换端口关联的处理协调器、发生器或使用者线程至少包含一个不属于并行查询进程时，可能会互相阻塞，从而导致死锁。 3、减少死锁的策略

本篇文章主要对Mybatis事物进行基础的介绍。先回顾JDBC事物，再了解Mybatis里面的事物应用。 1.JDBC的事务管理回顾 JDBC的事务管理是基于Connection对象实现的： 开启事务：connection.setAutoCommit(false) 提交事务：connection.commit() 回滚事务：connection.rollback() 2.事务的特性：ACID 原子性：事务是不可分割的。一个事务里的操作，不可能成功一半 一致性：事务提交前后，数据/状态是一致的 隔离性：事务并发时，事务应该是互不干扰相互独立的 持久性：事务一旦提交，数据就永久保存到磁盘上。 3.事务并发时可能存在的问题： ①脏读：一个事务里读取到另外一个事务未提交的数据。 ②不可重复读：一个事务里，多次读取的数据不一致。是受到了其它事务update的干扰。 ③虚读/幻读：一个事务里，多次读取的数据不一致。是受到了其它事务insert、delete干扰事务之间的隔离级别不够高，会导致事务并发问题。 使用隔离级别解决事务并发问题 隔离级别 脏读 不可重复读 虚读 read uncommitted 有 有 有 read committed 无 有 有 repeatable read 无 无 有 serializable 无 无 无 两种事物管理的方式： 手动提交 与 自动提交

数据库的基本语法的使用，很多，我也没有去整理，所以在这里就不介绍那些基本的语法了。如果对这方面有问题，我在这里给大家分享一个方法： 　　SQL语句应该怎样去优化？在职业生涯中，有一次维护一个项目中的一个模块。之前做的那个同事离职了，交给我来维护。我记得好像是七八张表吧，各种join、order by、distinct、group by.......看得头大。这样的SQL语句应该怎么优化呢？额......这怎么优化啊？建议从表的设计方面考虑吧。后来我也是这样做的，重新设计表，将表的数量减少，将数据更新到那写新表中去。即使不刷数据，流程中做下控制，时间久了，老表中的数据也都会更新到新表中去。 数据库设计步骤： 　　1、需求分析：大概明白需要存储什么 　　2、概要设计阶段：E-R图，表-属性-关系表，解决多方的沟通问题 　　3、详细设计，细致到表甚至字段 关系型数据库：面向对象的封装+关系 面向对象的思想来建表： 　　一对一：人----身份证；垂直分别的时候；相同主键/外键 　　一对多：订单----商品表；省-----市；公司-----员工；主外键表示 　　多对多：用户----菜单；学生----课程；女神----备胎；关系表/中间/映射表 三大范式： 　　第一范式：每一列保持原子性，不可分割 　　　　原子性：不可分割。 　　　　人----工作电话/家庭电话/移动电话，必须要拆分开

1、什么是分布式事务 分布式事务就是指事务的资源分别位于不同的分布式系统的不同节点之上的事务； 2、分布式事务产生的原因 2.1、数据库分库分表 在单库单表场景下，当业务数据量达到单库单表的极限时，就需要考虑分库分表，将之前的单库单表拆分成多库多表； 分库分表之后，原来在单个数据库上的事务操作，可能就变成跨多个数据库的操作，此时就需要使用分布式事务； 2.2、业务服务化 业务服务化即业务按照面向服务（SOA）的架构拆分整个网站系统； 比如互联网金融网站SOA拆分，分离出交易系统、账务系统、清算系统等，交易系统负责交易管理和记录交易明细，账务系统负责维护用户余额，所有的业务操作都以服务的方式对外发布； 一笔金融交易操作需要同时记录交易明细和完成用户余额的转账，此时需要分别调用交易系统的交易明细服务和账务系统的用户余额服务，这种跨应用、跨服务的操作需要使用分布式事务才能保证金融数据的一致性； 3、分布式事务原理简介 数据库本地事务（ACID） 说到数据库事务就不得不说，数据库事务中的四大特性 ACID： A：原子性(Atomicity)，一个事务(transaction)中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。 事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。 就像你买东西要么交钱收货一起都执行

X/Open DTP(Distributed Transaction Process)是一个分布式事务模型。这个模型主要使用了两段提交(2PC - Two-Phase-Commit)来保证分布式事务的完整性。 参考博文1中给除了基于DTP模型的分布式事务大致的流程： 而且，博客中提到：XA 协议描述了 TM 与 RM 之间的接口，允许多个资源在同一分布式事务中访问。XA 协议使用 2PC（Two Phase Commit，两阶段提交）原子提交协议来保证分布式事务原子性。两阶段提交是指将提交过程分为两个阶段，即准备阶段（投票阶段）和提交阶段（执行阶段）： 看到这里我不禁心生疑惑： 图中的步骤3和5存在的意义是什么呢 ？假如 将步骤3合并到步骤7中，将步骤5和并到步骤8中会不会有什么问题呢 ？因为在参考书5中介绍的两阶段提交，就是在准备阶段进行业务操作，在第二阶段进行提交或回滚。 带着这个疑惑，我又找到了参考博客2。博客中提到使用X/Open DTP编程的一般方式为： 1. 配置TM，通过TM或者RM提供的方式，把RM注册到TM。可以理解为给TM注册RM作为数据源。一个TM可以注册多个RM。 2. AP从TM获取资源管理器的代理（例如：使用JTA接口，从TM管理的上下文中，获取出这个TM所管理的RM的JDBC连接或JMS连接） 3. AP向TM发起一个全局事务。这时，TM会通知各个RM

一、概述 1. 事务：一个包含多个步骤的业务操作。如果这个业务操作被事务管理，则这多个步骤要么同时成功，要么同时失败。 2. 操作： 1. 开启事务 2. 提交事务 3. 回滚事务 3. 使用Connection对象来管理事务 * 开启事务：setAutoCommit(boolean autoCommit) ：调用该方法设置参数为false，即开启事务 * 在执行sql之前开启事务 * 提交事务：commit() * 当所有sql都执行完提交事务 * 回滚事务：rollback() * 在catch中回滚事务 二、代码 public class JDBCDemo10 { public static void main(String[] args) { Connection conn = null; PreparedStatement pstmt1 = null; PreparedStatement pstmt2 = null; try { //1.获取连接 conn = JDBCUtils.getConnection(); //开启事务 conn.setAutoCommit(false); //2.定义sql //2.1 张三 - 500 String sql1 = "update account set balance = balance - ? where id = ?"; /

Hibernate入门这一篇就够了 本博文主要讲解 介绍Hibernate框架，ORM的概念和Hibernate入门 ，相信你们看了就会使用Hibernate了! Hibernate是一种ORM框架，全称为 Object_Relative DateBase-Mapping ，在Java对象与关系数据库之间 建立某种映射，以实现直接存取Java对象 ！ 既然Hibernate是关于Java对象和关系数据库之间的联系的话，也就是 我们MVC中的数据持久层->在编写程序中的DAO层... 首先，我们来回顾一下我们在DAO层写程序的历程吧： 在DAO层操作XML，将数据封装到XML文件上，读写XML文件数据实现CRUD 在DAO层使用原生JDBC连接数据库，实现CRUD 嫌弃JDBC的Connection\Statement\ResultSet等对象太繁琐，使用对原生JDBC的封装组件-->DbUtils组件 我们来看看使用DbUtils之后，程序的代码是怎么样的： public class CategoryDAOImpl implements zhongfucheng.dao.CategoryDao{ @Override publicvoidaddCategory(Category category) { QueryRunner queryRunner = new QueryRunner