> "After a BEGIN EXCLUSIVE, no other database connection except for > read_uncommitted connections will be able to read the database and no other > connection without exception will be able to write the database until the > transaction is complete." > > This tells me that reads outside of a transaction would be permitted while an > exclusive transaction is taking place.
This works only when shared cache mode is turned on and only within the same process. Nothing uncommitted can be read between processes or between different connections in the same process when shared cache is turned off. Pavel On Thu, May 12, 2011 at 4:26 PM, John Deal <bassd...@yahoo.com> wrote: > Good question. Very possible my understanding is not complete. > > I have basically read and write transactions, each potentially with several > accesses to the DB. I want to ensure that if a write transaction is > happening, no read transactions are in progress since it would be possible to > have obtain incomplete data (mixture of some reads being valid but other no > longer valid because the write transaction changed them). In other words, a > read "transaction" (I do not use a transaction for the reads) consists of > multiple pieces of data that makeup a set that I want to ensure is valid as a > set. > > It is my understanding that a transaction (which I do use for the write > transaction which is also a set) locks the DB for writes but not reads. If a > transaction does lock the DB for exclusive access then you are correct, I do > not need the OS mutexes. Maybe I do not understand the following: > > "After a BEGIN EXCLUSIVE, no other database connection except for > read_uncommitted connections will be able to read the database and no other > connection without exception will be able to write the database until the > transaction is complete." > > This tells me that reads outside of a transaction would be permitted while an > exclusive transaction is taking place. > > If a write transaction is not taking place, I want to allow multiple reads > which the OS rwlock allows. > > Any enlightenment would be welcomed. > > Thanks. > > --- On Thu, 5/12/11, Roger Binns <rog...@rogerbinns.com> wrote: > >> From: Roger Binns <rog...@rogerbinns.com> >> Subject: Re: [sqlite] Multi-threading Common Problem >> To: sqlite-users@sqlite.org >> Date: Thursday, May 12, 2011, 4:01 PM >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 05/12/2011 09:38 AM, John Deal wrote: >> > I have been working for weeks on this and I feel there >> must be something simple I am overlooking. >> >> Why are you discarding SQLite's builtin and tested mutexes >> and then >> effectively reimplementing your own to get the same >> effect? >> >> Or bigger picture question what is it you are trying to >> achieve in the first >> place? >> >> Roger >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.11 (GNU/Linux) >> >> iEYEARECAAYFAk3MPIkACgkQmOOfHg372QQzjgCg3106pWiiUMuOQay+2ONv3G0c >> ZvQAnAvBFXI+A8ae8tV9yXRmz7IZgid6 >> =jehy >> -----END PGP SIGNATURE----- >> _______________________________________________ >> sqlite-users mailing list >> sqlite-users@sqlite.org >> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users >> > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
