[sqlite] Understanding table and database locking mechanism in shared cache mode and normal mode

On 31 Mar 2016, at 12:06am, Srikanth Bemineni wrote: > > In this case a new connection is > being given to a thread in shared cache mode to the database. If one of the > thread gets a SQLITE_LOCKED status for statement execution, we use try > again after some time assuming the other thread

[sqlite] Understanding table and database locking mechanism in shared cache mode and normal mode

Hi In shared cache mode the locking seems to be per table level basis. Which seems to not block my operations on the other tables in the same database. When there are multiple connections, any transaction is going to create a data base level lock, which may result in many write as well as read

[sqlite] Understanding table and database locking mechanism in shared cache mode and normal mode

Hi, if( (lastStatus == SQLITE_OK) && mystatement) { m_lastStatus = sqlite3_step(mp_statement); while( lastStatus == SQLITE_LOCKED || lastStatus == SQLITE_BUSY) { sleep(randomtime) lastStatus = sqlite3_step(mp_statement); } } My common

[sqlite] Understanding table and database locking mechanism in shared cache mode and normal mode

My application is a multi threaded application, which uses sqlite to store data on a file. Our current architecture of using sqlite in shared cache mode seems to be working absolutely fine. In this case a new connection is being given to a thread in shared cache mode to the database. If one of the

[sqlite] Understanding table and database locking mechanism in shared cache mode and normal mode

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 30/03/16 16:58, Simon Slavin wrote: > In both modes (whether you're using 'shared cache' or not) use > either > > https://www.sqlite.org/c3ref/busy_timeout.html The last time I dealt with shared cache mode, the busy timeout did not apply. You