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 ? 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)?
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
