您的位置:首页 > 其它

关于fastdb打开模式的说明

2013-09-10 10:30 225 查看
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、所有的数据修改操作,如果有并发要求,一定要及时提交
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: