数据库的锁与事务.ppt

数据库锁与事务问题研究 数据库锁与事务问题研究 数据库的锁 Hibernate的事务和并发 数据库的死锁 解决方案 数据库的锁 什么是数据库的锁 数据库的锁是为了解决多个用户同时对数据库的并发操作而带来数据不一致问题而存在的，它是数据库系统本身的一个多并发处理机制 在多并发系统中通常我们会遇到以下三种问题 丢失更新 脏读 不可重复读 对于并发控制的主要方法是封锁,锁就是在一段时间内禁止用户做某些操作以避免产生数据不一致问题。 锁的类型 数据系统定义的锁有以下三种基本模式 共享锁 (S) 更新锁 (U) 排它锁 (X) 其他的一些派生锁 意向锁 架构锁 大容量更新锁 数据库锁的种类 数据库锁的粒度 锁粒度是用来描述被封锁目标大小的,封锁粒度小则并发性高,但开销大,封锁粒度大则并发性低但开销小。各种锁的粒度和其对应的资源如下 资源 说明 RID 用于锁定单个行 KEY 索引中用于保护可序列化事务中的键范围的行锁 PAGE 页锁（数据库中的8KB页） EXTENT 扩展页锁（一组连续的八页） HoBT 堆或B树 TABLE 表锁 FILE 文件锁 DATABASE 数据库锁 数据库锁的隔离级别 数据库系统有四个隔离级别，不同的隔离级别定义了数据库系统使用锁的不同行为方式；通过对隔离级别的选择来控制数据库系统的锁是我们日常通用的锁管理方式。这四种隔离基本分别是： SERIALIZABLE：添加排他锁直到事务A结束，以此阻止其他事务对此范围内的select,insert,update等所有操作 REPEATABLE READ：对于读出的记录添加共享锁直到事务A结束，其他事务对此范围内的修改操作需要一直等待到事务A结束，查询操作不受影响 READ COMMITTED：在读取数据的时候添加共享锁，但是读取结束后就立即释放。其他的事务不需要等到事务A完全结束已经可以接触资源 READ UNCOMMITTED：不添加任何锁，其他的事务可以随时接触资源 HIBERNATE的事务和并发 在我们的网管系统中，通过Hibernate来管理程序与数据库的交互的 Hibernate对JDBC进行了轻量级的对象封装，Hibernate本身在设计时并不具备事务处理功能，平时所用的Hibernate的事务，只是将底层的JDBCTransaction或者JTATransaction进行了一下封装，在外面套上Transaction和Session的外壳，其实底层都是通过委托底层的JDBC或JTA来实现事务的调度功能的。 在这个图中最底层的QUERY(HQL)就是我们在页面开发的时候最直接接触的业务查询逻辑层，而第一、第二层则分别是负责启动hibernate(创建sessionfactory)和初始化hibernate(充当数据存储源代理，创建session对象)；其中的第三层里，session负责持久化对象的CRUD操作，transaction负责事务相关操作；transaction的处理将会直接影响到数据库的并发操作 HIBERNATE的事务和并发 HIBERNATE的锁 在这里hibernate引入了乐观锁和悲观锁的概念，与调用数据库本身的并发处理机制不同，这是hibernate自身定义的多并发处理机制。 乐观锁(Optimistic Locking)：乐观锁假定当前事务操纵数据资源时，不会有其他事务同时访问该数据资源，因此不作数据库层次上的锁定。为了维护正确的数据，乐观锁使用应用程序上的版本控制（由程序逻辑来实现的）来避免可能出现的并发问题 悲观锁(Pessimistic Locking)：悲观锁假定当前事务操纵数据资源时，肯定还会有其他事务同时访问该数据资源，为了避免当前事务的操作受到干扰，先锁定资源。尽管悲观锁能够防止丢失更新和不可重复读这类并发问题，但是它影响并发性能，因此应该很谨慎地使用悲观锁。 显然hibernate的乐观锁与悲观锁机制与数据库的锁机制有所不同，它是对数据库系统的多并发处理机制的一种有益补充。 数据库的死锁 死锁的原理：根据操作系统中的定义：死锁是指在一组进程中的各个进程均占有不会释放的资源，但因互相申请被其他进程所占用不会释放的资源而处于的一种永久等待状态 死锁的四个必要条件： 互斥条件(Mutual exclusion) 请求与保持条件(Hold and wait) 非剥夺条件(No pre-emption) 循环等待条件(Circular wait) 如何避免、处理死锁 上图列出了死锁的四个必要条件，我们只要想办法破掉其中的任意一个或多个条件，就可以避免死锁发生，一般有以下几种方法 按同一顺序访问对象 避免事务中的用户交互 保持事务简短并处于一个批处理中 使用较低的