fastdb的事务与恢复

请先看fastdb自带的文档，这里只对里面进行一些解释

 

fastdb只支持multiple-readers-single-write的封锁机制，就是说当是写锁时会封锁整个数据库，不充许进行其它操作，在看源代码时，也没找到死锁检查的部分，只找到了读锁向写锁升级的部分，而且封锁会持续到事务结束才放弃，这种锁机制造成了事务的实现也比较简单，

当向数据库中更新一条记录时，

1.要申请新的空间，就要修改bitmap中的置位，把0置为1表示已被占用，此时要把修改了置位的bitmap的页面拷贝一份，在新拷贝的那份上修改，原来那份不变，index记录的偏移相应修改

2.在申请的空间上放入新插入的记录，如果是修改的话，要把原记录拷贝一份，在新拷贝的进行修改，同时修改index ,如是新插入在新申请的oid中记录偏移，如是修改，就修改偏移

3.当事务结束时，把原来的未修改的bitmap页面释放，如果是修改的话，把原记录也释放，之后就是修改index 和 shadow index,使shadow index中的修改过的bitmap页面和记录的oid指向新的偏移，使index 和 shadow index内容一样

 

 

在一个事务的过程中，bitmap的页面和元组的页面（如果修改的话），都是需要重新拷贝的，只有index 和 shadowIndex 是不动的

事务很简单，恢复也就比较简单了，就是把Shadowindex中的内容覆盖掉index中的就可以了，因为没提交的时候，原内容是没有被释放的，

由于没有日志部分，所以恢复只能恢复到上次提交的状态，再向前恢复就不可能了，

另外，一旦物理文件损坏，就没办法了，只能恢复到以前备份的物理文件，这点使用起来很不方便

 

fastdb是用 index 同时存在一个拷贝 shadow index ，以及把要修改的bitmap页面 和 记录 拷贝一份来完成事务和恢复的，而且bitmap页面是整页拷贝的，不像记录，只把记录本身拷贝，而不是拷贝所在的页面

所有的对象oid，包括表，bitmap页面，记录的oid，除了预先只留的8K + 2 之后，之后就没有区分了，依靠oid是无法区分表和记录的，