1. The database is written by a single process who has an EXCLUSIVE LOCK
2. Only AFTER all data is being written, costumer can access it (read mode)
3. potentially, it is a single writer followed by multiple readers kind of flow
4. For the problem described we had also a single reader.
5. hence, I hardly think that this is a concurrency issue
6. the OS is linux in 64 bits mode
7. file system is NFS.
8. so, user launches an execution via local DRM (LSF i think) and from
a remote machine is a DB is generated, after DB is generated another
execution is launched and another remote machine access it in a read
mode and some "SELECT..." queries are used, then the corruption error
>* Answering your question below,*>* *>* yes , I believe that the costumer is using network*
You can read section 6.0 of
Consider using the "unix-dotfile" VFS instead of the standard "unix" VFS.
(Add the string "unix-dotfile" as the 4th argument to sqlite3_open_v2().)
The unix-dotfile VFS will use dot-file locking instead of posix advisory
locking. The unix-dotfile VFS will usually work better on NFS.
The down side of unix-dotfile is that will cut concurrency, but it sounds
like you are not using concurrency anyhow. Also, if a process crashes, it
might leave a stale dot-file lock that you'll need to clear manually.