I have stumbled upon the issue as described in http://sqlite.org/faq.html#q5 
(But use caution: this locking mechanism might not work correctly if the 
database file is kept on an NFS filesystem.)

The question is, do we have a workaround. Our application has to store data in 
user home directory (RHEL/SLES/CentOS) and the home directory might be on a NFS 
device (as is my home directory). 
stat -f -c %X /users/prakash returns nfs.

I am vaguely imagining if we could (at compile or run time) have SQLite use dot 
file locking.

Let me describe the problem I am facing.
The database file does not exist and the call to sqlite3_open, does not return 
(or atleast does not return as long as I waited ~10 mins). I killed the process 
using kill / kill -9, but process went into zombie state.
Also I observed that the database file got created (may not be usable) and 
another file nfs00..... was created and locked by my app.

I compiled the latest sqlite and ran the following command
sqlite /users/prakash/test.db
I got the sqlite command prompt, however, the command .tables resulted in hang.

So, again, I am trying to figure out a solution/workaround. Concurrency is not 
the most major concern and hence if we can use a different locking mechanism, 
that will be nice.


sqlite-users mailing list

Reply via email to