On Sunday, 28 April, 2019 11:23, Lullaby Dayal <lullaby.tec...@gmail.com> asked:
To answer your specific questions: >So my questions are:- >1. In auto-commit mode in serialized threading mode, how command >queueing works? auto-commit and transactions are an attribute of the connection and have nothing whatsoever to do with serialized threading mode. You may place a connection within a transaction either explicitly or implicitly from any thread at any time, just as you may commit or rollback that transaction on that connection from any thread at any time. The transaction status (and thus the "queueing" of updates as you put it) only applies to a connection. Serialized Threading mode is simply a safety net to ensure that you do not mutate shared state (the connection) from multiple threads at the same time. As you can imagine, if you were permitted to do this (update shared context at the same time) then all hell would break loose. Threading mode is simply a way to control access to shared state (the connection) from multiple threads at the same time. SERIALIZED MODE means "please check and enforce that I am not attempting to mutate shared context from multiple threads and protect me from the explosions that would result if I do so by not permitting it to happen". MULTITHREADING mode means "Do not bother to check whether or not I am attempting to mutate shared context from multiple threads and if I do so then permit the resulting explosions to annihilate me". SINGLE_THREAD mode means "I am only using a single thread in this program so do not do anything that may require multiple threads or thread local storage, nor check or protect me from any explosions resulting from me lying about this". >2. Multiple simultaneous calls to sqlite_exec() performing Multiple >write commands or read commands while write is in progress - will >this be handled by sqlite_exec() itself? Or does the application >need to do some kind of locking to avoid such situation as >mentioned in the FAQ? No, isolation is between CONNECTIONS and not between STATEMENTS (which are derived from the same connection). All things derived from a single connection share the same context. >In serialized mode, sqlite3 implements its own locking, right? Yes, however, serialized mode is simple to prevent simultaneous mutation of shared state (the connection) concurrently from multiple threads. It does not have anything whatsoever to do with "locking" or transactions or any other ACID property of the database. >Do application need to do a high level locking beyond this? No. Concurrency protection is inherent between connections (and things derived from DIFFERENT connection). SERIALIZED mode will prevent you from causing explosions that result from failing to follow the entrance requirements of the library but otherwise has nothing whatsoever to do with concurrency nor isolation. >3. Will there be a case the database can become corrupt or some >operations missed to get performed in such a case? Since isolation is between connections, then all changes made on a connection are visible to all other "things" on that connection at the instant those changes are made. That means that if you delete a row from a table while you are also reading that table, then that row will "vanish" at the time the update made. Since this will mutate the indexes on the table, any manner of result could ensue. This is why you should not do this and why you should utilize isolation (provided by connections) to prevent an "update" from occurring in the middle of reading. --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
