Does SQLITE are compatible with Openafs?

/* next line makes byte range locks always succeed,
 * even when they should block */
if (af->l_whence != 0 || af->l_start != 0 || af->l_len != 0) {
 DoLockWarning();
 afs_PutFakeStat(&fakestate);
 return 0;
}

I want to have many processes on many networked computers at the same time to access the same one through OpenAFS 1.4.12.1 SQLite database. There are few writes, so the single-write design of SQLite should not be a problem.

I want to know if this is possible. I can’t find two key information:

The SQLite documentation states “SQLite uses POSIX advisory locks to implement locking on Unix” It also warns that “your best defense is not to use SQLite for files on the network file system”. However, it does not seem to specify whether SQLite will only use entire file locking or whether it also uses byte range locking.

It is also difficult for me to find out which type of locking is supported by OpenAFS 1.4.12.1. Unfortunately, this unofficial source from 1998 is the best resource I can find. At that time, whole file locking was supported but not Byte range locking.

The official document only appears on this page, although its friendly title does not actually state whether the latest OpenAFS supports POSIX byte range locking.

Edit:
Is it possible? If so, are there any compile-time SQLite flags required?

I have been using SQLite for a while, and I have the “fortune” to deal with some locking issues. I am pretty sure that SQLite is on the Unix file system by default Byte range lock is used on

More precisely, it contains some code for alternative locking methods (for example, using flock() and dotlock-style for the entire file Lock). When compiled with the SQLITE_ENABLE_LOCKING_STYLE option, it will try to automatically detect the correct locking method of the underlying file system.

The automatic detection code contains some hard-coded situations (such as “ufs “, “nfs” and “smbfs”), none of which is AFS. If there is no hard-coded match, SQLite will try to use fcntl() to obtain the byte range lock of the file. Then assume if If the fcntl() call succeeds, you can use byte range lock.

This is where OpenAFS comes in. Obviously ([1],[2],[3])OpenAFS has been applied to user space for a long time Program description byte range lock. From the openafs-1.4.14 source code:

/* next line makes byte range locks always succeed,
 * even when they should block */
if (af->l_whence != 0 || af->l_start != 0 || af->l_len != 0) {
 DoLockWarning();
 afs_PutFakeStat( &fakestate);
 return 0;
}

One sentence: Ouch!

It allows byte-range locks to succeed anyway. On Linux, you can imagine worse: it uses the kernel infrastructure to provide byte-range locks between processes on the same system. This means The application can’t just fork a new process and test the locking mechanism – byte-range locks seem to work fine, while failing terribly protect files from remote processes.

In short: you can’t Use OpenAFS to reliably use unmodified SQLite. Most other network file systems also have problems, so it is recommended to avoid using network file systems altogether.

Some possible solutions are in no particular order:

>Use an appropriate DBMS, such as PostgreSQL. If you can do this, you will be better in the long run.
>If a full DBMS is overkill, implement your own server for your application.
> Modify the SQLite source code on OpenAFS to default to flock(). I’m not sure if this will work properly, because OpenAFS has a long history ([1], [2]), even ordinary flock( ), there are also locking issues, but you won’t know it before testing.
>Use OpenAFS user space to implement your own OpenAFS VFS for SQLite, not through the kernel.
>Try your luck with another network file System.

No matter what you do, if SQLite3 and shared database files are involved in any way, you must perform a lot of testing.

Edit:

One The opinion provider recommends using the dotlock file mechanism. I didn’t have much research into the OpenAFS source code, but at first glance it seems to support the open(O_CREAT|O_EXCL) method of creating dotlock files used by SQLite. If it does Works as expected, then if it is forced to use the dotlock method, SQLite may indeed be available for OpenAFS.

That is to say, dotlocks is sufficient to solve the problems of regular local file systems without complicating the network file system Sex is introduced into the mix – that’s why I didn’t propose it in the first place.