I like the idea of FLoM-based VFS !!

I am not sure I am up to actually doing it, but this should be as good a 
locking mechanism as any other.

Thank you, Keith.

Roman

________________________________________
From: sqlite-users [sqlite-users-boun...@mailinglists.sqlite.org] on behalf of 
Keith Medcalf [kmedc...@dessus.com]
Sent: Saturday, September 28, 2019 12:48 AM
To: SQLite mailing list
Subject: Re: [sqlite] disable file locking mechanism over the network

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
https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmailinglists.sqlite.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fsqlite-users&amp;data=02%7C01%7Croman.fleysher%40einstein.yu.edu%7C3e48038bb3254b2b636608d743cf2ce2%7C04c70eb48f2648079934e02e89266ad0%7C1%7C1%7C637052429406868157&amp;sdata=iJc7whQWoukCo1QUL8yAL73j5wcG5e%2Bw8TFU2RkHY1U%3D&amp;reserved=0
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to