数据库并发控制机制

我们在使用多用户数据库时常常会碰到数据更新失败、删除失等情况，如果有多个用户且同时访问一个数据库则当他们的事务同时使用相同的数据时可能会发生并发问题。

并发问题包括：

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

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

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

详细描述：

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

例如，两个编辑人员制作了同一文档的电子复本。每个编辑人员独立地更改其复本，然后保存更改后的复本，这样就覆盖了原始文档。最后保存其更改复本的编辑人员覆盖了第一个编辑人员所做的更改。如果在第一个编辑人员完成之后第二个编辑人员才能进行更改，则可以避免该问题。

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

例如，一个编辑人员正在更改电子文档。在更改过程中，另一个编辑人员复制了该文档（该复本包含到目前为止所做的全部更改）并将其分发给预期的用户。此后，第一个编辑人员认为目前所做的更改是错误的，于是删除了所做的编辑并保存了文档。分发给用户的文档包含不再存在的编辑内容，并且这些编辑内容应认为从未存在过。如果在第一个编辑人员确定最终更改前任何人都不能读取更改的文档，则可以避免该问题。

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

例如，一个编辑人员两次读取同一文档，但在两次读取之间，作者重写了该文档。当编辑人员第二次读取文档时，文档已更改。原始读取不可重复。如果只有在作者全部完成编写后编辑人员才可以读取文档，则可以避免该问题。

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

例如，一个编辑人员更改作者提交的文档，但当生产部门将其更改内容合并到该文档的主复本时，发现作者已将未编辑的新材料添加到该文档中。如果在编辑人员和生产部门完成对原始文档的处理之前，任何人都不能将新材料添加到文档中，则可以避免该问题。

从上面可以看到，解决并发主要是用到了锁和事务。
锁 ：给记录或表加上锁是为了对当前操作对象加上一个状态表示位，
让其它用户在获取编辑权限时有了判断。
事务：是为了保证一组操作的完整性。(要么就全部成功，要么就全部失败)

一般处理并发问题时我这样做：
1.开启事务。
2.申请写权限，也就是给对象(表或记录)加锁。
3.如果失败，则结束事务，过一会重试。
4.如果成功，也就是给对象加锁成功，防止其它用户再用同样的方式打开。
5.进行编辑操作。
6.写入所进行的编辑结果。
7.如果写入成功，则提交事务,完成操作。
8.如果写入失败，则回滚事务，取消提交。
9.(7.8)两步操作已释放了锁定的对象，恢复到操作前的状态