On 03/18/2012 11:26 AM, Arnav Aggarwal wrote:
On Sat, Mar 17, 2012 at 12:07 PM, Arnav Aggarwal<
arnav.aggarwal.2...@gmail.com> wrote:
On Sat, Mar 17, 2012 at 11:51 AM, Roger Binns<rog...@rogerbinns.com>wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 16/03/12 22:50, Arnav Aggarwal wrote:
I don't have any choice of using a different filesystem..
I'd suggest you write your own VFS then. You can choose exactly how
locking is done. It isn't that much work and you can map to the exact
semantics of the filesystem rather than pretending it is unix which it
evidently isn't.
My system behaves quite similar to that of unix and mostly POSIX
compliant. But, "fcntl" locks are not supported.
Is there any known problem using a "unix-dotfile" vfs ?
In such a scenario, can I safely delete the lock file and journal file
(if size 0) ?
Depends on why they are size zero. If your crummy filesystem doesn't
implement barriers correctly then it is quite possible that they shouldn't
be zero length.
(I'm assuming your want your database to survive unexpected power
failures)
May be I can leave the journal files as it is. I believe sqlite code can
take care of them.
But, lock directories must be deleted else the application fails to start.
Can these be safely deleted at apllication start up before opening the
database ?
Guys, Sorry for being impatient and posting this again.
Any comments on this issue ?
Just to summarize, I am using "dotfile" locking. Only one instance of
application will run (it may be multithreaded). The sqlite code is
statically linked with the application. This is the only application that
can access the database file.
On application crash, lockfiles are sometimes not removed due to which
application fail to restart.
My question, can I safely remove the lockfile on application startup before
opening the database and before creating any thread ?
If, at some point, you are sure that no processes have
the database file open, you can safely delete any old
lock files.
Don't ever delete a journal or wal file though of course.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
