> But I sqlite can still check the number of db connections open Even though as Michael have shown this is possible (with guaranteed results only when run as root) it will still have races. Because if you see only one process accessing database file at the end of transaction and only one process at the beginning of the next one it doesn't guarantee that there was no other processes writing to database between those checks.
And btw I think scanning all contents in /proc directory will be much much slower than checking for hot-journal. Pavel On Wed, Aug 10, 2011 at 2:13 PM, Sreekumar TP <sreekumar...@gmail.com> wrote: > Ok.. But I sqlite can still check the number of db connections open and > optimise the checking=> as long as there is only one writer, do not check > for hot journals. > > Can a database have two connections opened with two different journal modes > ? > > On Wed, Aug 10, 2011 at 11:35 PM, Pavel Ivanov <paiva...@gmail.com> wrote: > >> > If you have one reader and many writers, consider PRAGMA >> journal_mode=WAL; >> >> Richard meant "one writer and many readers" of course. >> >> >> If the other process opens the db connection as read_only, will the hot >> >> journal check be still done (during queries operations of the second >> >> process)? >> >> >> > >> > How is the second process suppose to know whether or not the other >> process >> > used read_only? >> >> And even those who opened db connection as read_only will check for >> hot journal before executing any query. >> >> >> Pavel >> >> On Wed, Aug 10, 2011 at 1:44 PM, Richard Hipp <d...@sqlite.org> wrote: >> > On Wed, Aug 10, 2011 at 1:35 PM, Sreekumar TP <sreekumar...@gmail.com >> >wrote: >> > >> >> Ok, its getting a bit clear. >> >> If there is only one process that is writing to the database, but has >> more >> >> than one process that reads the database, the locking mode can still be >> >> exclusive ? >> >> >> > >> > PRAGMA locking_mode=EXCLUSIVE; means "exclusive'. Only one process can >> > access. >> > >> > If you have one reader and many writers, consider PRAGMA >> journal_mode=WAL; >> > >> > >> > >> >> If the other process opens the db connection as read_only, will the hot >> >> journal check be still done (during queries operations of the second >> >> process)? >> >> >> > >> > How is the second process suppose to know whether or not the other >> process >> > used read_only? >> > >> > >> >> >> >> >> >> >> >> >> >> On Wed, Aug 10, 2011 at 10:54 PM, Richard Hipp <d...@sqlite.org> wrote: >> >> >> >> > On Wed, Aug 10, 2011 at 1:09 PM, Simon Slavin <slav...@bigfraud.org> >> >> > wrote: >> >> > >> >> > > >> >> > > On 10 Aug 2011, at 6:01pm, Sreekumar TP wrote: >> >> > > >> >> > > > Thanks for the explanation. The journal mode was OFF which means >> >> there >> >> > > is >> >> > > > no journal file created. So why is it the check still performed ? >> >> > > >> >> > > Because the journal mode might have been 'ON' the last time that >> >> > database >> >> > > was used. >> >> > > >> >> > >> >> > More importantly, the journal mode might be 'ON' in the other process >> >> that >> >> > crashed in the middle of a transaction. >> >> > >> >> > >> >> > >> >> > > >> >> > > > On Wed, Aug 10, 2011 at 10:24 PM, Richard Hipp <d...@sqlite.org> >> >> wrote: >> >> > > > >> >> > > >> On Wed, Aug 10, 2011 at 12:40 PM, Sreekumar TP < >> >> > sreekumar...@gmail.com >> >> > > >>> wrote: >> >> > > >> >> >> > > >>> The 179148 failures on 'access' system call is due to access >> check >> >> of >> >> > > two >> >> > > >>> files - the journal file and the wal-file. >> >> > > >> >> > > Well, the file is obviously not being opened 179148 times. I >> thought >> >> it >> >> > > checked for these files only when sqlite3_open() was being run. Is >> it >> >> > > checking for these files every time a command is executed ? Surely >> >> that >> >> > is >> >> > > unnecessary and a source of a large reduction in speed. >> >> > > >> >> > >> >> > SQLite must check for hot journals at the start of each transaction. >> >> > >> >> > Or, more precisely, SQLite must check for hot journals whenever it >> starts >> >> > reading the database again after a period of time when another process >> >> > might >> >> > have been writing to the database (and might have crashed while >> writing). >> >> > >> >> > That's when PRAGMA locking_mode=EXCLUSIVE blocks the hot-journal >> checks. >> >> > If >> >> > your process has exclusive access to the database, it is not possible >> for >> >> > another process to write to the database (and crash in the middle of >> >> > writing). >> >> > >> >> > >> >> > >> >> > > >> >> > > Simon. >> >> > > _______________________________________________ >> >> > > sqlite-users mailing list >> >> > > sqlite-users@sqlite.org >> >> > > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users >> >> > > >> >> > >> >> > >> >> > >> >> > -- >> >> > D. Richard Hipp >> >> > d...@sqlite.org >> >> > _______________________________________________ >> >> > 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 >> >> >> > >> > >> > >> > -- >> > D. Richard Hipp >> > d...@sqlite.org >> > _______________________________________________ >> > 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 > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
