> I think it's a misuse of Sqlite and not a real bug. He adds code to ensure > only one thread access the database in a multithread application. For the > description, I infer he uses -DSQLITE_THREADSAFE=2 (multithread), where a > -DSQLITE_THREADSAFE=1 (serialized) solve the problem better because the > code to ensure only one thread access the database in multithread app, is > sqlite own code, don't need to reinvent the wheel.
As I read it each thread had its own connection, and some "connection" held an update lock on the database while another connection (thread/process, is irrelevant) attempted to access the database. This of course results in a "database is locked" error on the second connection. If a busy timeout handler is in effect, then it will retry until the retry interval expires. However, in some cases the compiler had decided to compile SQLite to use 1 second sleep resolution rather than nanosecond sleep resolution. This means that while the standard nanosecond sleep resolution may result in thousands of tries to gain access to the database in just one second of elapsed time, increasing the resolution of the timer by a million-fold means that the busy-wait timeout must also be increased by a million-fold to obtain the same probabilistic behaviour. In other words, while busy_timeout of 5 seconds may be sufficient when using the nanosecond resolution sleep, you would need a busy_timeout value of 5000000 seconds to obtain the same probabilistic behaviour with a sleep resolution measured in seconds. > Please, pay attention to my first two words, "I think", it shows my > opinion about the problem as is described, not a real solution to other > problems. There is no problem with multithreaded access and an access from a second thread (even simultaneous access from multiple threads) with threadsafe=2 could cause a locked database error. The lock belongs to the connection and if that connection obtains an update lock, then that update lock applies to all threads on which calls into the engine may be made on that connection, and it is quite impossible to get a database locked result. > > > Simon. > --- --- > Eduardo Morras <emorrasg at yahoo.es> > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
