This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
When running repeated sqlite queries with different arguments, the application's handles keeps increasing until it crashes. Here's my query: Snippet Snippetvar signature = (from s in unitOfWork.Query<Signature>() where s.File.Uuid == uuidString select s).FirstOrDefault();
The unit of work is not throwing in the dispose (that statement is surrounded by a using on a LightSpeedContext.CreateNewUnitOfWork(), which I temporarily replaced with a try catch while manually calling dispose). I also tried surround it with a try finally and calling GC.Collect() and GC.WaitForPendingFinalizers(). If I put a return before the query, all is ok - right after, and I got a memory leak. Is the query being cached somehow? I tried lightSpeedContext.Cache = null, but no luck. On one machine Process Explorer showed many handles to the sqlite database, which led me here in the first place. |
|
|
|
|
The query is not cached within LightSpeed -- results are cached, but those don't keep handles to the database. It sounds as though you are creating multiple units of work (and therefore multiple connections) -- is that right? If so, my guess would be that the IUnitOfWork objects are not being disposed for some reason, or that when we call Dispose() on the SQLite connections then they are not being released properly, perhaps due to connection pooling. Can you provide code that demonstrates the problem? |
|
|
|
|
Thanks for the reply. I verfied that the Dispose was being called and not throwing. I eventually found out that it was an issue with system.data.sqlite.dll. I was using the Managed Only implementation along with the native sqlite3.dll. I guess that's risky business. Using the combined dll works fine. |
|
|
|
