On Feb 21, 2015, at 5:36 PM, Simon Slavin <slavins at bigfraud.org> wrote:
> > On 21 Feb 2015, at 9:01pm, Yuriy Stelmakh <yuriy128 at gmail.com> wrote: > >> When using read uncommitted pragma, is it possible to get a row of data >> where some columns reflect state of that row at one point, while others at >> another? For example when you are reading in one thread while writing in >> another. > > No. They'll all be either one thing or the other. In other words, even with > the PRAGMA set, SQLite is still transaction-safe. It uses a lock on the > entire database to prevent the problem you described. > No, not with columns, but it is possible with rows, depending on how the two treads are interacting. SQLite rows are essentially self-contained, so any time a row is updated it is updated as a complete unit. This is not true of rows within a table, however. Understand that READ UNCOMMITTED only applies to connections within the same process that are also using a shared cache (sqlite3_enable_shared_cache()). If, in the situation you describe, the threads are using different connections that are NOT using a shared cache, then the writer thread will ?see? any updates it has already made within the uncommitted transaction, while another reader thread (using a different connection) will not? it will see the data as it existed when the transaction was started. This has nothing to do with READ UNCOMMITTED, however, that?s how it always works when not using a shared cache (or when not using the same connection for reads and writes). Basically the connection context that created the transaction will see the actions it has performed, while all other connections will not see the changes until the transaction is committed (which, of course, is the whole point of transactions). -j -- Jay A. Kreibich < J A Y @ K R E I B I.C H > "Intelligence is like underwear: it is important that you have it, but showing it to the wrong people has the tendency to make them feel uncomfortable." -- Angela Johnson
