FastDB不同访问模式带来的影响

本文原创作品，如需转载请注明来源，作者：姜涛， towerjt@gmail.com

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、所有的数据修改操作，如果有并发要求，一定要及时提交