If you have only one thread accessing the file. Then you shouldn't need to do any type of locking per se. I would leave the file locks.
I would not induce your own mutex. Sqlites locking should be adequate. I have a system where there are two threads sharing a single db and each thread createing and release access to various DB's all without using any mutexes for sqlite synchronization. Is this a single database file with each thread having its own connection? If that is the case then sure you should expect and handle the sqlite_busy. Did you configure/compile with: configure --enable_threadsafe ? Mark Brown <[EMAIL PROTECTED]> wrote: No, not a soft link. :) Based on other posts I have read about threading performance and SQLite, it seems like most people like to use a single thread. I'm going to change our application to use a system-wide mutex for thread synchronization and see if that improves our results. I'm still thinking our problems may be low-level file i/o bugs with our OS, so perhaps taking out the file-based .lock scheme will help. Thanks, Mark > -----Original Message----- > From: Ken [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 15, 2007 12:39 PM > To: sqlite-users@sqlite.org > Subject: RE: [sqlite] SQLITE_BUSY error in multi-threaded environment > > > It should not. > > As long as those two connections are not used across threads > and point to truely different databases. > > They wouldn't be a soft link would they? I > > ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
