On 15 October 2012 12:32, Keith Medcalf <kmedc...@dessus.com> wrote:
>
> Define "clients".  Do you mean multiple client processes running on a single 
> computer against a database hosted on an attached local device, such as on a 
> Terminal Server for example?  Or do you mean multiple clients connecting over 
> LANMAN/CIFS/NFS to a database file sitting on a remote fileserver?

It's the second one. The database file is being accessed over the network.

> If file locking is working correctly, you cannot have multiple writes to a 
> database.  Write operations to the database are exclusive.

As Simon correctly guessed, the database isn't actually being
corrupted; I'm just getting an error that suggests that it is. So I
suspect the writes are not conflicting, but one is failing (possibly)
due to another happening at the same time and whatever locking/waiting
not being observed properly results in this 'malformed' error rather
than a blocking error.

> You may wish to try forcing locks to be acquired sooner when updating the 
> database by using BEGIN IMMEDIATE or perhaps even BEGIN EXCLUSIVE before 
> updating the database, and COMMIT when you are done.  You will then also need 
> a busy-timeout so that other readers/writers will wait for that operation to 
> complete.  You can set the timeout when creating the connection with sqlite3 
> in python, or by using PRAGMA busy_timeout

Thanks - I'll give that a shot.

> Latency of locking operations over network connections can play havoc, 
> however.  It is possible if you are using a network mounted database file 
> that the write operations are not being flushed properly and or the locks are 
> not propagating in a timely fashion.
>
> http://www.sqlite.org/lang_transaction.html
> http://www.sqlite.org/lockingv3.html

Reading up now...

Cheers,
Larry
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to