Hi Ritesh, Please direct responses to the SQLite list, as others may be able to provide input as well. I'm a SQLite user as you are, not a one man SQLite support team:)
Inline. On Fri, 16 Sep 2005, Ritesh Kapoor wrote: >Hi Christian, > >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. 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. >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. Yes. The lock states are internal to SQLite and completely opaque to the developer. > >Futher I am looking for some kind of example or documentation where the >aggregate queries and these two functions are explained in more detail - >sqlite3_create_function() >sqlite3_aggregate_function() There is comprehensive documentation on the website: http://www.sqlite.org/docs.html API reference: http://www.sqlite.org/capi3ref.html >Please let me know if you are aware of this. > >Thanks and Regards, >Ritesh Christian > >Christian Smith wrote: > >>On Fri, 16 Sep 2005, Amin Azez wrote: >> >> >> >>>FAQ 7 >>> >>>(7) Can multiple applications or multiple instances of the same >>>application access a single database file at the same time? >>> >>> Multiple processes can have the same database open at the same time. >>>Multiple processes can be doing a SELECT at the same time. But only one >>>process can be making changes to the database at once..... >>> >>> >>> >>>This answer fails to make clear whether or not the multiple readers can >>>read while the single writer is writing, or whether the writer blocks >>>the readers and the readers block pending writers (like mysql non-innodb >>>tables) >>> >>>Could someone please clairify this point. >>> >>> >> >> >>Locking in SQLite is detailed here: >>http://www.sqlite.org/lockingv3.html >> >>In summary: >>SQLite uses multiple readers/single writer locking. A writer can operate >>concurrently with readers until it is ready to commit or spill data from >>it's cache. In this case, it waits for readers to finish, then gets an >>exclusive write lock and writes it's data. Thus, the following concurrency >>is available to SQLite: >> >> time ----> >>Reader >-------------| >>Reader >-------------| >>Reader >----------| >>Writer >-------c***----| >>Reader >***********-------------| >> >>Key: >>- Executing query >>c Commit >>* Blocked by lock >> >> >>>Start of query >>> >>> >>| End of query >> >>The last reader above is blocked from starting by the writer until the >>writer commits. If the writer commits before the last reader has finished, >>it is blocked. >> >>It might be worth raising a ticket (http://www.sqlite.org/cvstrac/tktnew) >>to have the FAQ reference the locking document. >> >> >> >> >>>Sam >>> >>> >>> >> >>Christian >> >> >> > -- /"\ \ / ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL X - AGAINST MS ATTACHMENTS / \
