Some ideas:
Sqlite may return that the database is locked immediately if it detects a
deadlock situation. Something like: a different connection holds a reserved
lock (waiting for read connections to close so it can promote to exclusive),
and the current connection tries to promote from a read lock to a reserved or
exclusive lock. Busy timeout will never resolve this situation so the
connection attempting to promote just returns that the database is locked.
You can also get guaranteed timeouts if you use multiple connections on the
same thread, or if your threading logic causes a deadlock. An example might be:
//...
DataReader dataReader = outerCmd.ExecuteReader()
foreach (var row in dataReader)
{
using (SQLiteConnection innerCon = GetNewConnection())
//attempt to write with inner conn
}
The above might happen in a called function to obscure what is happening. Such
things might be valid on a different dbms that does table or row level locking,
but can't be used with SQLite's Db level locking (I got bitten by this when I
thought 'oh yeah, change from sql server to sqlite? I'll just update the SQL
and change the providers. The logic will translate fine.')
Finally, I have seen inexplicable timeouts if I mix SQLite and
TransactionScope. In my case the sqlite connections didn't need to participate
in the transaction so I fixed it by setting enlist=false on the connection
string and not investigating further.
> On 4 Jul 2018, at 5:14 am, Simon Slavin <slav...@bigfraud.org> wrote:
>
>> On 3 Jul 2018, at 8:08pm, Phani Rahul Sivalenka
>> <rahul.sivale...@walkingtree.tech> wrote:
>>
>> As per our observation, the initial write operations on the sqlite db file
>> throw "db is locked" error. After a certain time (around an hour) write
>> operations start working and we are able to do all the operations as
>> required. [...]
>
>> “data
>> source=/var/www/html/ChargerDatabase.db;DateTimeKind=Utc;Version=3;Pooling=True;Synchronous=Off;journal
>> mode=Memory;Busy Timeout=30000;Default Timeout=30”
>
> Test each of your timeouts by removing one, then the other, then both. See
> if the removal of one of them changes the described behaviour.
>
> Simon.
> _______________________________________________
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
