mbdavid / LiteDB

LiteDB - A .NET NoSQL Document Store in a single data file
http://www.litedb.org
MIT License
8.52k stars 1.24k forks source link

LiteDB.LiteException: 'Collection 'nameOfCollection' lock timeout when entering in reserved mode after 00:01:00 #1432

Closed ghost closed 4 years ago

ghost commented 4 years ago

LiteDB.LiteException HResult=0x80131500 Message=Collection 'UserAccount' lock timeout when entering in reserved mode after 00:01:00 Source=LiteDB StackTrace: at LiteDB.Engine.LockService.EnterReserved(String collectionName) at LiteDB.Engine.Snapshot..ctor(LockMode mode, String collectionName, HeaderPage header, UInt32 transactionID, TransactionPages transPages, LockService locker, WalIndexService walIndex, DiskReader reader, Boolean addIfNotExists) at LiteDB.Engine.TransactionService.gcreate|38_0(<>c__DisplayClass38_0& ) at LiteDB.Engine.TransactionService.CreateSnapshot(LockMode mode, String collection, Boolean addIfNotExists) at LiteDB.Engine.LiteEngine.<>cDisplayClass26_0.b0(TransactionService transaction) at LiteDB.Engine.LiteEngine.AutoTransaction[T](Func2 fn) at LiteDB.Engine.LiteEngine.Update(String collection, IEnumerable1 docs) at LiteDB.LiteCollection`1.Update(T entity) at LiteDB.LiteRepository.Update[T](T entity, String collectionName) at ViettelIM.Core.Persistence.Repositories.UserAccountRepository.Update(UserAccount resource) in D:\Projects\CSharp\Desktop app\Viettel Change SIM AI\ViettelIM.Core\Persistence\Repositories\UserAccountRepository.cs:line 35 at ViettelIM.Core.Services.UserAccountService.<>cDisplayClass5_0.b0() in D:\Projects\CSharp\Desktop app\Viettel Change SIM AI\ViettelIM.Core\Services\UserAccountService.cs:line 98 at System.Threading.Tasks.Task`1.InnerInvoke() at System.Threading.Tasks.Task.<>c.<.cctor>b274_0(Object obj) at System.Threading.ExecutionContext.RunFromThreadPoolDispatchLoop(Thread threadPoolThread, ExecutionContext executionContext, ContextCallback callback, Object state)

This exception was originally thrown at this call stack: LiteDB.Engine.LockService.EnterReserved(string) LiteDB.Engine.Snapshot.Snapshot(LiteDB.Engine.LockMode, string, LiteDB.Engine.HeaderPage, uint, LiteDB.Engine.TransactionPages, LiteDB.Engine.LockService, LiteDB.Engine.WalIndexService, LiteDB.Engine.DiskReader, bool) LiteDB.Engine.TransactionService.CreateSnapshot.create|38_0(ref LiteDB.Engine.TransactionService.<>c__DisplayClass38_0) LiteDB.Engine.TransactionService.CreateSnapshot(LiteDB.Engine.LockMode, string, bool) LiteDB.Engine.LiteEngine.Update.AnonymousMethod0(LiteDB.Engine.TransactionService) LiteDB.Engine.LiteEngine.AutoTransaction(System.Func<LiteDB.Engine.TransactionService, T>) LiteDB.Engine.LiteEngine.Update(string, System.Collections.Generic.IEnumerable) LiteDB.LiteCollection.Update(T) LiteDB.LiteRepository.Update(T, string) ViettelIM.Core.Persistence.Repositories.UserAccountRepository.Update(ViettelIM.Core.Domain.Models.UserAccount) in UserAccountRepository.cs ... [Call Stack Truncated]

mbdavid commented 4 years ago

You are not keeping a transaction open? Or a query IEnumerable without dispose?

Andrey-N commented 4 years ago

I got same error on a pretty easy code and this issue too https://github.com/mbdavid/LiteDB/issues/1431 Downgrade to 5.0RC version fix all and work great, for me

lbnascimento commented 4 years ago

@mincasoft Could you test it with v5.0.1?

VVSoft commented 4 years ago

You are not keeping a transaction open? Or a query IEnumerable without dispose?

Faced the same problem without dispose, for me an increase to v5.0.1 solved the problem.

Andrey-N commented 4 years ago

5.0.1 solved the problem for me

JensSchadron commented 4 years ago

Closing the issue as it has been resolved by updating to 5.0.1

behroozbc commented 3 years ago

hi I get same error in 5.0.10 {"Collection 'SerialPortData' lock timeout when entering in write mode after 00:01:00"}

FelixLorenz commented 9 months ago

I have had a similar issue (probably).

Exception was:

Collection 'MyCollection' lock timeout when entering in write mode after 00:01:00

... thrown by the same logic that was rock stable when awaited from the UI synchronization context. But as soon as a SignalR handler tried to execute this method these exception occured. Looks like in your stack trace, that the DB calls were also done from a different synchronization context.

Manually awaiting this method from the UI synchronization context again fixed all issues immediately. Like so:

private void MySignalrEventHandler()
{
    Task.Factory.StartNew(
        async () =>
        {
            await MyUsuallyRockstableMethod(); // executing up to thousands of upserts on tens of collections
        },
        CancellationToken.None,
        TaskCreationOptions.None,
        taskSchedulerForDesiredSyncContext // eg get via TaskScheduler.FromCurrentSynchronizationContext(); while on UI thread and pass around
        ); 
}

Hope it helps!