On Mon, 9 May 2005, Helmut Tschemernjak wrote:
Hello,
sqlite3 3.2.1 gives SQLITE_LOCKED errors if one process updates the database and another accesses it. Most retries will fail if the other processes is working e.g. many inserts.
Here is my idea:
Keep a list of up to 32 pid_t of waiting processes in the database file. After one statement is completed send a SIG_USR1 message of the first process in the list and shift out the first PID and add yourself to the end of this list any wait for some time e.g. (20ms).
The second process receives a signal and can start using the DB and will automatically wakeup the next client PID. The same could be done on Windows using events.
This means there would be no polling/retry required to access the DB from a second process on the same machine.
Are there any other workarounds? I will try the sqlite3_busy_handler
the pids will grow stale and you'll end up sending a signal to some random proecess. other issue is that the pid may not be on the same host - we store alot of config info in nfs mounted sqlite dbs. the are however, very occasionally updated by a process that locks the whole db first. in this case the pid hold the lock is almost never on the same machine.
cheers.
-a -- =============================================================================== | email :: ara [dot] t [dot] howard [at] noaa [dot] gov | phone :: 303.497.6469 | renunciation is not getting rid of the things of this world, but accepting | that they pass away. --aitken roshi ===============================================================================
