Closed teknynja closed 3 months ago
Note that this will probably also be an issue if an end-user abandons iterating a Find(...)
result as well...
I ran into this issue too as an end user (with FindById, it also left an open transaction and an open cursor). Using Find(f => f.Id == ...).FirstOrDefault() had the same issue. .LastOrDefault instead worked in my case. The transactions not being cleaned up were the primary issue in my case, but I did notice it leaving open cursors when I was testing workarounds.
It would be interesting @teknynja if you can roll in #2436 on top of the v5.0.19 codebase to see if it resolves your problem. Note that I've done the same and it looks like it resolves #2435 for us, but it is definitely not present in v5.0.19.
@mbdavid would appreciate a new build that includes #2436, as we are looking for an official build that includes this fix, and our application's release date is coming soon.
Unfortunately, I've switched to a different DB solution and probably won't be able to pursue this issue further.
I reproduced this issue using this simple test
[Fact]
public void TestTest()
{
var data = DataGen.Person(1, 100).ToArray();
using (var db = new LiteDatabase("filename=:memory:"))
{
var person = db.GetCollection<Person>();
person.Insert(data);
db.BeginTrans();
var results = person.FindAll();
var result = results.First();
db.Commit();
}
}
And I can confirm that #2436 fixes it.
Thank you for reporting this issue.
This issue has been resolved in the latest version of LiteDB. Please update to the latest version of LiteDB to resolve this issue. If the issue persists, please let us know.
Version v5.0.19
Describe the bug Using
FindOne()
is holding a read lock and open cursor because it is not completely iterating the return result from the delegatedFind()
call. This results in the theClose()
/Dispose()
methods skipping the cleanup (and failing to merge the pending transactions!)I can work around this issue by using
Find(...).ToArray().First()
instead ofFindOne(...)
but that is an ugly hack and could be very inefficient if the predicate returns a large number of results.This was not an issue in v5.0.17, and I first noticed it on 5.0.18. I thought the fix for #2435 in v5.0.19 might address this problem but it still persists. I'm surprised that there aren't other reports of lingering log files since the release of v5.0.18?
Code to Reproduce
Expected behavior
FindOne()
should release locks and cursors when it completes, and the log file should be merged and deleted on disposing the database.