[Digikam-devel] problems with digikam3.db into a nefs partition

Gilles Caulier caulier.gilles at gmail.com
Wed Mar 7 09:59:11 GMT 2007


Try to stress the database using a large taging image/comment or rating. The
problem apprears about multiple access on DB duing a wrong DB lock.

If you take a look into SQlite FAQ, you can read :

Q : Can multiple applications or multiple instances of the same application
access a single database file at the same time?

R: Multiple processes can have the same database open at the same time.
Multiple processes can be doing a SELECT at the same time. But only one
process can be making changes to the database at any moment in time,
however.
SQLite uses reader/writer locks to control access to the database. (Under
Win95/98/ME which lacks support for reader/writer locks, a probabilistic
simulation is used instead.) But use caution: this locking mechanism might
not work correctly if the database file is kept on an NFS filesystem. This
is because fcntl() file locking is broken on many NFS implementations. You
should avoid putting SQLite database files on NFS if multiple processes
might try to access the file at the same time. On Windows, Microsoft's
documentation says that locking may not work under FAT filesystems if you
are not running the Share.exe daemon. People who have a lot of experience
with Windows tell me that file locking of network files is very buggy and is
not dependable. If what they say is true, sharing an SQLite database between
two or more Windows machines might cause unexpected problems.
We are aware of no other embedded SQL database engine that supports as much
concurrancy as SQLite. SQLite allows multiple processes to have the database
file open at once, and for multiple processes to read the database at once.
When any process wants to write, it must lock the entire database file for
the duration of its update. But that normally only takes a few milliseconds.
Other processes just wait on the writer to finish then continue about their
business. Other embedded SQL database engines typically only allow a single
process to connect to the database at once.
However, client/server database engines (such as PostgreSQL, MySQL, or
Oracle) usually support a higher level of concurrency and allow multiple
processes to be writing to the same database at the same time. This is
possible in a client/server database because there is always a single
well-controlled server process available to coordinate access. If your
application has a need for a lot of concurrency, then you should consider
using a client/server database. But experience suggests that most
applications need much less concurrency than their designers imagine.
When SQLite tries to access a file that is locked by another process, the
default behavior is to return SQLITE_BUSY. You can adjust this behavior from
C code using the sqlite3_busy_handler() or sqlite3_busy_timeout() API
functions."

Gilles

2007/3/7, Fabien <fabien.ubuntu at gmail.com>:
>
> Gilles Caulier wrote:
> >
> > Just a notice about SQlite and NFS. On LinuxFR.org forum (in French), an
> > user have reported than SQLite work fine with NFS version >= 4. NFS 3 do
> > not work.
> >
> > Look this link : http://linuxfr.org/2007/03/06/22160.html
> > <http://linuxfr.org/2007/03/06/22160.html>
> >
> > If there is somebody witch have an NFS4 server ready to use with
> > digiKam, i would to have a fresh report about this point... Take a care
> > to test, i recommend to use a test account with a fresh album library
> > path. Do not try to use it in production because there is a risk to
> > corrupted the database.
>
> Well, I'd like to test it, but I must confess I can't reproduce the
> problem, even with a linux NFS server (nfsv3).
> When I try, it works perfectly :)
> When does an error occur ?
>
> I tried to import pictures, add comments, edit,... : everything is ok.
>
> --
> Fabien
>
> _______________________________________________
> Digikam-devel mailing list
> Digikam-devel at kde.org
> https://mail.kde.org/mailman/listinfo/digikam-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-devel/attachments/20070307/09c44551/attachment.html>


More information about the Digikam-devel mailing list