事务的实现，隔离级别与锁

基本就是靠log, 或者说undo log

经典的转帐问题，需要A的账户减去金额，B的账户增加金额，如果A减去了金额，而B账户增加金额的时候掉电，怎么办？

方案：在执行transaction之前save 事务要涉及的数据，transaction结束后要log 成功结束标志End Transaction。系统恢复的时候如果发现某个事务没有log End Transaction，说明这个事务没有成功，恢复之前保存的值。

总结：声明事务的时候保存涉及的数据值，事务结束时候要Confirm，相当于ACK，看到这个ACK就代表数据成功发送给Persistence层， 否则代表没成功，恢复之前的值。可以推广到不是system down的情况，任何步骤没有成功，可以直接rollback，用之前值覆盖已经update的值，或者不rollback，在connection结束时候发现transaction没有end，因为没有执行tran.commit()，或者执行时候异常，也可以判定事务不成功，回滚。

其实CopyOnWrite也是实现事务的方式，类似listingsLibrarian，每次更新都新产生一个版本，成功了更新版本号，否则就都是老版本，不会出现一部分数据是新版本一部分数据是老版本。

4种问题：1）更新丢失. 2)脏读（读到别的事务更新但未提交的数据，之后却被回滚了）3）不可重复读（第二次读同样的数据，值不同）4）幻读，再次读同样的数据，有新增的行或者有些行被删除了

1)解决更新丢失问题，需要写写互斥，两个事务都要更新同一个数据，第二个事务要等，对应隔离级别叫Read Uncommited，因为没有写-读互斥，第一个事务写，第二个事务读，可以看到第一个事务的更新。

2)解决脏读问题，需要写-读互斥，第一个事务写，第二个事务读也不行，需要等待，（等待第一个事务提交），Read Commited

3)解决不可重复读问题，需要读-写互斥，第一个事务读，第二个事务不能写，对应隔离级别叫 Repeatable Read

4) 解决幻读问题，也是读-写互斥，但更严，不仅是相同的数据不能写，增加数据删除数据也不行，对应隔离级别 Serialized

一般数据库默认隔离级别是 Repeatable Read，也就是说本次事务做判断依据的数据，不会变，一致性可以保证，类似一个线程做判断的condition, 不会被其他线程干扰