数据库---多事务并发访问问题(脏读...)（转）

 

 数据库带来的并发问题包括：   

 　　1.丢失或覆盖更新。(幻像读)

 　　2.未确认的相关性（脏读）。

 　　3.不一致的分析（非重复读）。

详细描述如下：

一，丢失更新

  当多个事务选择同一行，然后基于最初选定的值更新该行时，会发生丢失更新问题。每个事务都不知道其它事务的存在。最后的更新将重写由其它事务所做的更新， 这将导致数据丢失。　　

 当事务A和事务B同时修改某行的值，

 1.事务A将数值改为1并提交

 2.事务B将数值改为2并提交。这时数据的值为2，事务A所做的更新将会丢失。

解决办法：对行加锁，只允许并发一个更新事务。(hibernate中的悲观锁，乐观锁)

二，未确认的相关性(脏读)

　　当第二个事务选择其它事务正在更新的行时，会发生未确认的相关性问题。第二个事务正在读取的数据还没有确认并且可能由更新此行的事务所更改。

  1.Mary的原工资为1000, 财务人员将Mary的工资改为了8000(但未提交事务)       

  2.Mary读取自己的工资 ,发现自己的工资变为了8000，欢天喜地！(在缓存中读取)

  3.而财务发现操作有误，回滚了事务,Mary的工资又变为了1000 像这样,Mary记取的工资数8000是一个脏数据。

 解决办法：如果在第一个事务提交前，任何其他事务不可读取其修改过的值，则可  以避免该问题。

三，不一致的分析(非重复读)

　　当第二个事务多次访问同一行而且每次读取不同的数据时，会发生不一致的分析问题。不一致的分析与未确认的相关性类似，因为其它事务也是正在更改第二个 事务正在读取的数据。然而，在不一致的分析中，第二个事务读取的数据是由已进行了更改的事务提交的。而且，不一致的分析涉及多次（两次或更多）读取同一 行，而且每次信息都由其它事务更改；因而该行被非重复读取。

 

 在一个事务中前后两次读取的结果并不致，导致了不可重复读。

  1.在事务1中，Mary 读取了自己的工资为1000,操作并没有完成

  2.在事务2中，这时财务人员修改了Mary的工资为2000,并提交了事务.

  3.在事务1中，Mary 再次读取自己的工资时，工资变为了2000

 

解决办法：如果只有在修改事务完全提交之后才可以读取数据，则可以避免该问题。

 

 四.幻像读 　　 　

 　当对某行执行插入或删除操作，而该行属于某个事务正在读取的行的范围时，会发生幻像读问题。事务第一次读的行范围显示出其中一行已不复存在 于第二次读或后续读中，因为该行已被其它事务删除。同样，由于其它事务的插入操作，事务的第二次或后续读显示有一行已不存在于原始读中。

 

目前工资为1000的员工有10人。

  1.事务1,读取所有工资为1000的员工。

  2.这时事务2向employee表插入了一条员工记录，工资也为1000

  3.事务1再次读取所有工资为1000的员工共读取到了11条记录，

 

解决办法：如果在操作事务完成数据处理之前，任何其他事务都不可以添加新数据，则可避免该问题

--------------------------------------------------------------------------------------------------------------

锁争用：

关系型数据库，如 SQL Server，使用锁来避免多用户修改数据时的并发冲突。当一组数据被某个用户锁定时，除非第一个用户结束修改并释放锁，否则其他用户就无法修改该组数 据。

有些数据库，包括SQL Server，用锁来避免用户检索未递交的修改记录。在这些系统中，如果用户A在修改一组记录，则其他用户只有等用户A修改完毕了，才能检索。