现在的位置: 首页 > 综合 > 正文

关于fastdb打开模式的说明

2018年10月19日 ⁄ 综合 ⁄ 共 1034字 ⁄ 字号 评论关闭

http://tower.iteye.com/blog/309325

FastDB中不同的访问DataBase的模式在程序中能体现不一样的结果。
从试验可以知道,不同访问模式主要体现在对表的锁上。
(具体的试验,大家如果觉得有必要,可以自己做一下,用
subsql -access [read-only concurrent-read concurrent-update normal]
可以指定访问数据的模式,然后自己构建相关测试用例进行测试
dbDatabase::dbAllAccess,一旦某个进程使用该模式访问表,如果该进程使用了insert、update、delete等修改数据的操作,
其他访问该库的进程的所有操作(包括open、select)都会被阻塞,直到该操作提交或回滚
dbDatabase::dbConcurrentUpdate,使用该模式访问表,如果某个进程对数据进行修改性的操作,同时另外的进程使用
dbDatabase::dbReadOnly或者dbDatabase::dbConcurrentRead读取数据,不会出现阻塞的情况。
但是dbDatabase::dbReadOnly会把未提交的脏数据读出来;而dbDatabase::dbConcurrentRead则不会
如果多个进程都使用dbDatabase::dbConcurrentUpdate,实际效果和dbDatabase::dbAllAccess一样,一旦一个进程修改了数据,
其他进程所有的操作(包括open、select)都将阻塞,直到该操作提交或回滚
结论:
FastDB没有提供商用数据库的记录锁甚至是页级锁的机制,锁的范围是一个DataBase文件,
所以在日常的使用过程中:
1、仔细分析业务需求,如果你只需要访问数据,那么最好是使用dbDatabase::dbReadOnly或者是
dbDatabase::dbConcurrentRead。这样的话,你的访问操作不会因为这个表被其他进程修改数据而阻塞。
2、如果一个表有不止一个使用者,那么涉及修改数据的进程应该使用dbDatabase::dbConcurrentUpdate,
而只读的进程使用则使用dbDatabase::dbConcurrentRead。
3、如果表只有一个使用者,则可以根据需要,使用dbDatabase::dbAllAccess或者dbDatabase::dbReadOnly
4、所有的数据修改操作,如果有并发要求,一定要及时提交

【上篇】
【下篇】

抱歉!评论已关闭.