I’m using System.Data.SQLite to query a database with c#/linq.
The rows I want to display contain data from various tables. What I currently do is to query one table to get a complete list of items which I place in a DataGrid. Thanks to virtualization I can query the other tables lazily, as the relevant Row comes into view. This works fine.
Now I want to begin filling in the missing data in the rows immediately, but asynchronously. But I get an exception “DataReader has been closed” , every time I do the lazy loading code in a different thread. Has this to do with the fact that the “original” linq query was done from another thread?
Any idea how I can fix this?
Here is some code that hopefully sums up the problem
//Main thread---
//Start the search
_startEvent.Set();
_mainLoadEvent.WaitOne();
_mainLoadEvent.Reset();
//Worker thread---
_startEvent.WaitOne();
_startEvent.Reset();
SearchAllLiterature(); //Fills _searchResults with rows
_mainLoadEvent.Set(); //Signal to mainthread that all rows are loaded
//Fill in some details for every row, that come from various sources, we'll need them later
foreach (var r in _searchResults)
r.LazyLoadText();
//SearchResultRow.cs
public string Author
{
get
{
LazyLoadText();
return _author;
}
set
{
_author = value;
}
}
//Called by the worker thread or by the DataGrid when a new row comes into view
public void LazyLoadText()
{
lock (this)
{
if (_lazyLoadTextCompleted) return;
_lazyLoadTextCompleted = true;
}
var sb = new StringBuilder();
//this will result in a SQL-query
var authors = from a in _source.ReferenceOrganization
orderby a.Person.LastName
select a.Person;
Author = ConcatAuthors(authors, sb);
//...more queries...
}
Raising the _mainLoadEvent after the lazy-loading-loop does not show the same problem.
The problem is also solved if I put a static lock around the entire code of the LazyLoad-method. Seems like it is not okay to start queries concurrently, but can this be true?
I found out that the SQLite data contexts are not thread safe. As the linq-queries where implicitly using the same context I ran into a problem. Using several contexts gets rid of the problem, but unfortunately the contexts have separate caches (or so it seems) so background loading I do one thread won’t benefit a later search on another thread. Which basically was the whole idea.
Loading in the background still is useful if you are not currently accessing the database in the main thread. Although I haven’t really figured out an elegant way to determine that.