这段时间由于开发项目,重新学习了数据库的并发控制和锁机制。数据库就是通过锁机制来解决并发问题的。。主要就是两种锁,共享锁和排他锁(也叫独占锁)。在执行select语句的时候需要给操作对象(表或者一些记录)加上共享锁,但加锁之前需要检查是否有排他锁,如果没有,则可以加共享锁(一个对象上可以加n个共享锁),否则不行。共享锁通常在执行完select语句之后被释放,当然也有可能是在事务结束(包括正常结束和异常结束)的时候被释放,主要取决与数据库所设置的事务隔离级别。
执行insert、update、delete语句的时候需要给操作的对象加排他锁(我感觉在执行insert的时候应该是在表级加排他锁),在加排他锁之前必须确认该对象上没有其他任何锁,一旦加上排他锁之后,就不能再给这个对象加其他任何锁。排他锁的释放通常是在事务结束的时候(当然也有例外,就是在数据库事务隔离级别被设置成Read Uncommitted(读未提交数据)的时候,这种情况下排他锁会在执行完更新操作之后就释放,而不是在事务结束的时候)。
数据库是支持在一个事务中进行自动锁升级的,例如,在某个事务中先执行select语句,后执行update语句,这两条语句操作了同一个对象,并且假定共享锁是在事务结束的时候被释放的。如果数据库不支持自动锁升级,那么当update语句请求排他锁的时候将不能成功。因为之前select语句的共享锁没有被释放,那么事务就进入了无限等待,即死锁。有了自动锁升级,在执行update语句的时候就可以将之前加的共享锁升级为排他锁,但有个前提,就是这个共享锁必须是本事务自己加的,而且在操作对象上没有在加其他任何锁,否则共享锁是不能被升级为排他锁的,必须等待其他锁的释放。
在看《精通Hibernate》的时候,里面还提到了更新锁。因为通常在执行更新操作的时候要先查询,也就是我们通常会在update语句和delete语句中加where子句。那么,有的数据库系统可能会在执行查询的时候先给操作对象加共享锁,然后在更新的时候加排他锁,但这么做会有问题,也就是如果两个事务同时要更新一个对象,都先给这个对象加了共享锁,当要更新的时候,都请求升级锁,但由于这个对象上存在对方事务加的共享锁。。所以无法升级。这样两个事务就在等待对方释放共享锁,进入死锁状态。更新锁就是为了解决这个问题,即在执行查询操作的时候加的不是共享锁而是更新锁(一个对象上只能有一个更新锁和n个共享锁),当要更新的时候,再将更新锁升级为排他锁,升级前提是这个对象上只有本事务加的更新锁,没有其他任何锁了。其实,,我想,如果在执行查询的时候就给事务加排他锁不也能解决死锁问题吗,但这样似乎会减弱系统的并发性能。
现在说说数据库的事务隔离级别。
在《精通Hibernate》中提到了4种数据库事务隔离级别:
Read Uncommitted:读未提交数据(这个通常很少用)
使用这种隔离级别并不是说在读取或者更新数据的时候不加锁。。其实还是加锁的,只是在执行完操作之后马上释放锁。而不是等到事务结束之后再释放。对于共享锁,排他锁都是这样。
Read Committed:读已提交数据(这个很常用,也常是数据库默认的设置)
这种隔离级别共享锁在读取数据之后马上释放。。而排他锁则是在事务结束的时候再释放。
Repeatable Read:可重复读
这种隔离级别共享锁和排他锁都是在事务结束的时候再释放的。因此叫“可重复读”,即一个事务所读取的数据是不会被别的事务更新的。。。在事务执行过程中任何时候都可以读取刚才读过的数据。读过的数据是不会被改变的,直到事务结束。
Serializable:串行化
共享锁和排他锁也是在事务结束的时候被释放,和Repeatable Read不同的是,通常,Repeatable Read。。在读取数据的时候。。都是对一条条记录加共享锁的。而Serializable的共享锁则是对整个表加的,这样不但读取的数据不会被别的事务修改。。。在同一个表中的其他未被读取的数据也不会被修改,,甚至不用担心读到新加入这个表中的数据(根本无法往表中加数据),所以这种隔离级别是不会出现虚读的。
执行insert、update、delete语句的时候需要给操作的对象加排他锁(我感觉在执行insert的时候应该是在表级加排他锁),在加排他锁之前必须确认该对象上没有其他任何锁,一旦加上排他锁之后,就不能再给这个对象加其他任何锁。排他锁的释放通常是在事务结束的时候(当然也有例外,就是在数据库事务隔离级别被设置成Read Uncommitted(读未提交数据)的时候,这种情况下排他锁会在执行完更新操作之后就释放,而不是在事务结束的时候)。
数据库是支持在一个事务中进行自动锁升级的,例如,在某个事务中先执行select语句,后执行update语句,这两条语句操作了同一个对象,并且假定共享锁是在事务结束的时候被释放的。如果数据库不支持自动锁升级,那么当update语句请求排他锁的时候将不能成功。因为之前select语句的共享锁没有被释放,那么事务就进入了无限等待,即死锁。有了自动锁升级,在执行update语句的时候就可以将之前加的共享锁升级为排他锁,但有个前提,就是这个共享锁必须是本事务自己加的,而且在操作对象上没有在加其他任何锁,否则共享锁是不能被升级为排他锁的,必须等待其他锁的释放。
在看《精通Hibernate》的时候,里面还提到了更新锁。因为通常在执行更新操作的时候要先查询,也就是我们通常会在update语句和delete语句中加where子句。那么,有的数据库系统可能会在执行查询的时候先给操作对象加共享锁,然后在更新的时候加排他锁,但这么做会有问题,也就是如果两个事务同时要更新一个对象,都先给这个对象加了共享锁,当要更新的时候,都请求升级锁,但由于这个对象上存在对方事务加的共享锁。。所以无法升级。这样两个事务就在等待对方释放共享锁,进入死锁状态。更新锁就是为了解决这个问题,即在执行查询操作的时候加的不是共享锁而是更新锁(一个对象上只能有一个更新锁和n个共享锁),当要更新的时候,再将更新锁升级为排他锁,升级前提是这个对象上只有本事务加的更新锁,没有其他任何锁了。其实,,我想,如果在执行查询的时候就给事务加排他锁不也能解决死锁问题吗,但这样似乎会减弱系统的并发性能。
现在说说数据库的事务隔离级别。
在《精通Hibernate》中提到了4种数据库事务隔离级别:
Read Uncommitted:读未提交数据(这个通常很少用)
使用这种隔离级别并不是说在读取或者更新数据的时候不加锁。。其实还是加锁的,只是在执行完操作之后马上释放锁。而不是等到事务结束之后再释放。对于共享锁,排他锁都是这样。
Read Committed:读已提交数据(这个很常用,也常是数据库默认的设置)
这种隔离级别共享锁在读取数据之后马上释放。。而排他锁则是在事务结束的时候再释放。
Repeatable Read:可重复读
这种隔离级别共享锁和排他锁都是在事务结束的时候再释放的。因此叫“可重复读”,即一个事务所读取的数据是不会被别的事务更新的。。。在事务执行过程中任何时候都可以读取刚才读过的数据。读过的数据是不会被改变的,直到事务结束。
Serializable:串行化
共享锁和排他锁也是在事务结束的时候被释放,和Repeatable Read不同的是,通常,Repeatable Read。。在读取数据的时候。。都是对一条条记录加共享锁的。而Serializable的共享锁则是对整个表加的,这样不但读取的数据不会被别的事务修改。。。在同一个表中的其他未被读取的数据也不会被修改,,甚至不用担心读到新加入这个表中的数据(根本无法往表中加数据),所以这种隔离级别是不会出现虚读的。