View Ticket
Not logged in
Ticket Hash: 63cc0caf78c9f5d25961833a1cf96bd189b76dc9
Title: SQLiteLog logs Error into Trace, but dll doesn't propagate error outside
Status: Closed Type: Incident
Severity: Important Priority: Medium
Subsystem: Integration_Via_PInvoke Resolution: Works_As_Designed
Last Modified: 2019-12-08 19:07:50
Version Found In: 1.0.111
User Comments:
anonymous added on 2019-11-07 09:20:17:
we are using System.Data.SQLite v1.0.111 with SQLite.CodeFirst v1.5.2.28 and EntityFramework v6.3.0.
We also use serilog to log our stuff and we add tracelistener into our logging aswell.

From code we have multiple threads/tasks that are accessing the DB.
For every operation we open new DbContext and after commit, we dispose it.
This operation can be read, write or both. e.g. finding something in DB, modifying it and updating it in db.

We don't see any data corruption, but something not from our code is logging SQLite error into our logs.

After downloading sources of System.Data.SQLite I found, that it is a Trace.WriteLine from SQLiteLog.cs aprox. line 671.

The trace looks like this:
10:06:20.8824554 +01:00 [DBUG] [1] SQLite error (5): database is locked in "SELECT
[Project2].[C1] AS [C1],
[Project2].[ServerGuid] AS [ServerGuid],
[Project2].[C9] AS [C2],
[Project2].[C2] AS [C3],
[Project2].[Id] AS [Id],
[Project2].[JobType] AS [J
10:06:21.0356220 +01:00 [DBUG] [1] SQLite error (5): database is locked in "SELECT
[Extent1].[Id] AS [Id],
[Extent1].[Value] AS [Value],
[Extent1].[SettingName] AS [SettingName],
[Extent1].[ModifiedDateTime] AS [ModifiedDateTime]
FROM [SettingValuePc] A

But your library doesn't throw anything to us, so we think, that the library handles this error in some way internally (maybe by retrying) and finishes possibly successfully all the requests.

The odd thing about this is, that the message it cut off.

For now we can repro it on our private code, but if necessary I can hopefully provide limited repro repo on github for you.

My questions are:
Can this SQLite error introduce any corruption inside SQLite data?
Can we somehow turn off this kind of logging from you library? So that it doesn't log internal errors into Trace? I haven't found an easy way yet.
Should we be using only one instance of DBContext at one time, so that this error doesn't ever occur? We can get the dbcontext under locks, but it would be our last resort, because we don't want to throttle out app.


mistachkin added on 2019-11-15 05:06:35:
If an exception is not being thrown, then the trace messages you are seeing are