Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] Transactions are not removed in LiteDB 5.0.18 #2435

Closed
martijnboland opened this issue Feb 21, 2024 · 8 comments
Closed

[BUG] Transactions are not removed in LiteDB 5.0.18 #2435

martijnboland opened this issue Feb 21, 2024 · 8 comments
Labels

Comments

@martijnboland
Copy link

Version
5.0.18

Describe the bug
We use a single IDatabase instance registered as singleton. Our application performs reads and writes from many different threads. After a little while, LiteDB starts throwing exceptions that the max number of transactions is reached. While inspecting TransactionMonitor, we only see an increasing number of transactions.

With 5.0.17 everything works fine and transactions are released properly.

Code to Reproduce

for (var i = 0; i < 110; i++)
{
    await Task.Run(() =>
    {
        try
        {
            var result = _collection.FindById(key);
        }
        catch (Exception ex)
        {
            // Do something with exception. After 100 iterations, the max number of transactions will be reached
        }
    });
}

Expected behavior
The code above should run without exception.

@icegothic
Copy link

Hi, I also have a "Maximum number of transactions is reached." issue on my project with versions 5.0.18 & 5.0.19! Do I need to adapt my code in some way?

Note: version 5.0.17 works fine for me too.

@hizume
Copy link
Contributor

hizume commented Feb 23, 2024

This problem occurs even in the case of a single thread.
It is reproduced in the following code:

static void Main()
{
    // Create a new database.
    using var database = new LiteDatabase("test.db");

    var collection = database.GetCollection("test");
    collection.Insert(new BsonDocument { ["_id"] = 1 });

    for (int i = 0; i < 101; i++)
    {
        try
        {
            collection.FindById(1);
        }
        catch (LiteException ex)
        {
            // An exception is thrown when i reaches 100.
            Console.WriteLine(ex.Message);
        }
    }
}

I will send a pull request to fix it.

@dgodwin1175
Copy link

dgodwin1175 commented Feb 23, 2024

@mbdavid Assuming this fix has been tested and verified, can we get a new release that includes it?

Note that we rolled this fix into 5.0.19 and found that it resolves the "Maximum number of transactions reached" error, and also the DiskWriterQueue locking issue #2307 which has been preventing us from upgrading to v5.

@alexanderdibenedetto
Copy link

Hi - what's the update on this? I see a PR linked as open. It would be good to get this issue fixed so we can update.

@kjetilgloppen
Copy link

I saw the same issue when upgrading from 5.0.12 to 5.0.19. Version 5.0.17 is the only workable solution for now it seems...

@FelixLorenz
Copy link

Hi together, are there any updates on this? Also still staying with 5.0.17 due to this issue

@PatrickSlamp
Copy link

PatrickSlamp commented May 20, 2024

I have an update on this issue. Not sure if this is the right spot to put it, but I noticed something with transactions not being removed. As shown in the image below when using FirstOrDefault the transaction is not removed, when using ToList() in my case fixed it. Maybe some with more elaborate knowledge of the library can confirm my suspicion. (Edit: also maybe to mention there is only one entry in the database not sure if that also matters).
image

@JKamsker
Copy link
Collaborator

JKamsker commented Jun 4, 2024

This issue has been addressed and fixed in the latest commit.
A new release is coming shortly.
Reopen this issue or open a new one if this issue persists in the upcoming version please.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants