On 31 Mar 2016, at 12:06am, Srikanth Bemineni <bemineni.srikanth at gmail.com> 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 holding the lock would have > either failed or committed the transaction. > > Recently we moved to our connection type from shared cache to normal mode, > to see if there is any significant improvement in performance as suggested > by team member. Right now we have multiple database connections to same > database. We started to see lot of SQLITE_LOCKED hangs.
In both modes (whether you're using 'shared cache' or not) use either https://www.sqlite.org/c3ref/busy_timeout.html or https://www.sqlite.org/pragma.html#pragma_busy_timeout to set a timeout of a minute (really. a minute). See if that sorts out your problem. If you do this you do not need any retry mechanism in your own code: If SQLite returned _BUSY or _LOCKED then it has already done the retrying you told it to do. > 1. Does a transaction lock ,will lock the table or the whole data base > connection.? All locks in SQLite are for the whole database. > 2. What is the major difference in locking when compared to shared cache > mode. ? Sharing the cache is sharing the lock. In other words two connections sharing a cache are not able to lock each other out. For a detailed description (which you don't really need at this time) see <https://www.sqlite.org/lockingv3.html> Simon.
