On Friday, 27 September, 2019 22:11, Roman Fleysher <roman.fleys...@einstein.yu.edu> wrote:
>Based on the link you provide, it looks like I need unix-none VFS and >specify it as: >ATTACH 'file:demo2.db?vfs=unix-none' AS demo2; Yup. I think you can also do that when opening the file on the sqlite3_open_v2 call by using the same URI format. I think using nolock=1 without specifying a VFS does the same thing ... ie, using a filename of 'file:demo2.db?nolock=1' >FLoM will be ensuring sequential access. The journaling, as I understand, >is independent of locking and will still work. That is robustness to >crashes will remain. unix-none just disables file lock requests, which >are the cause of the overhead. Is this correct? I haven't looked at the actual code for the VFS but that is my impression. The description for using the nolock=1 URI parameter says that you must have the application "serialize writes" in order to maintain consistency and if you are using FLoM to synchronize application access to the sqlite3 api, I would think that would cover it. The nolock=1 specifically says that it disables "file locking operations" only but maintains the change detection logic which should presumably maintain cache consistency (I think the purpose of the nolock=1 is simply to allow "generic" vfs selection, by appending -none to the default vfs name -- ie, so that if you are running on Windows it uses win32-none instead of win32, and on unix uses unix-none instead of unix). As an aside, it might be interesting to derive another VFS from the standard "unix" VFS which just replaces the locking operations with synchronization using FLoM, so that nothing special at all is required at the application level other than selecting a different VFS layer. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
