-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/12/2011 01:26 PM, John Deal wrote: > Good question. Very possible my understanding is not complete.
This document has the full details: http://www.sqlite.org/lockingv3.html >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 You do know you can use transactions for reads? Or use multiple database connections to get isolation. If you worry about the efficiency of the latter then don't - ie get your code correct and then worry about performance. I recommend against the use of shared cache mode on general purpose computers (as opposed to embedded devices with trivial amounts of memory) because it changes some API behaviour (especially busy handling) and the amount of memory "wasted" is a rounding error. In any event it looks like I am not understanding some deeper aspect of what you are doing. My underlying point remains - there is absolutely no need to remove or workaround SQLite's builtin mutexes. They ensure that threaded code does not screw things up and are thoroughly tested/developed. Any question that starts with "so I removed/changed/subverted SQLite's existing mutexes" will be followed with a response where you'll need to prove that doing so isn't the cause. It is ok to augment them with your own locking but even that should not be necessary. Roger -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk3MyPkACgkQmOOfHg372QTTXgCcCa2bDbYH9WKQ2J2fPYhKLHPX DBgAoLoj+uRJ3GDIHWGU7TfgNXxDAuAH =exlM -----END PGP SIGNATURE----- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
