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 execute for all the my thread is some what like this. In shared
cache mode I used always end up with SQLITE_LOCKED as Roger Binns
mentioned. Now I end up with an hanging SQLITE_BUSY. Is there some kind of
a dead lock situation between threads that can cause this in normal mode.
I did change all my transaction with BEGIN IMMEDIATE to get a lock for the
each thread, so that my write and updates finish.
Srikanth
On Wed, Mar 30, 2016 at 8:02 PM, Roger Binns <rogerb at rogerbinns.com> wrote:
> -----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 had to manually manage the timeout/retries yourself. This
> is by design:
>
> https://sqlite.org/src/tktview/ebde3f66fc64e21e61ef2854ed1a36dfff884a2f
>
> In the APSW doc I recommend against using shared cache mode, as it
> doesn't have any benefits except for very small memory systems.
>
> Roger
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iEYEARECAAYFAlb8dyEACgkQmOOfHg372QQhhQCbBoKrBu40ZgroyJOPB8WVy4To
> hcsAn0f8rx1h+foMBH0r4YVYo3pmc9Nc
> =lNHi
> -----END PGP SIGNATURE-----
> _______________________________________________
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
