Christian Smith wrote:
I went through the link you had sent. This page mentions 5 different types of locks which are provided by the pager module in SQLite. Could you please clarify these 2 doubts - 1. My application uses our own Mutex variables to allow single reader/writer operation - this is no longer required.
I'd suggest you keep a wrapper between SQLite and your application though; with the option of locking out other instances of itself.
Correct. SQLite handles locking and concurrency. But you must handle the case where you cannot execute because of a lock. Check out: http://www.sqlite.org/capi3ref.html#sqlite3_busy_handler http://www.sqlite.org/capi3ref.html#sqlite3_busy_timeout Alternatively, handle SQLITE_BUSY in your code to retry a failed query some time in the future.
According to past discussions on the list there are instances where you'd get SQLITE_BUSY even if you have set the sqlite3_busy_timeout or handler. So you always have to check for that return value. If you're using threads you need to check for SQLITE_SCHEMA in that same loop ( I am assuming you would retry on SCHEMA and BUSY errors ). This is partly why a wrapper between SQLite and the application seems useful.
2. The 5 lock types mentioned on the documentation page are acquired by processes/threads on their own and as a programmer i can leave all these details for the pager to handle.
You can manipulation the locking using the different transaction levels. http://www.sqlite.org/lang_transaction.html Regards, Kervin
