Version
Which LiteDB version/OS/.NET framework version are you using. v5.1 current branch state (at 2021-04-26)
Describe the bug
LiteDB is rising issues with SlimLock.
First one:
ENSURE: current process already locked at the SharedEngine implementation, within the OpenDatabase method.
Second one:
The read lock is being released without being held.
This one occurs at LiteDB.Engine.LockService.ExtiTransaction()
followin the stack trace, it happens when the TransactionService.Finalize() is called upon disposing it within ReleaseTransaction methon in Transaction Monitor.
Code to Reproduce
This is the part of a big solution that access the litedb a lot, no simple example to reproduce
Expected behavior
No exception upon file write/read.
Screenshots/Stacktrace
Additional context
Any ideas how to work around this?
Would using the LockRecursionPolicy.SupportsRecursion help for the first issue?
Version
Which LiteDB version/OS/.NET framework version are you using. v5.1 current branch state (at 2021-04-26)
Describe the bug
LiteDB is rising issues with SlimLock.
First one:
ENSURE: current process already locked at the SharedEngine implementation, within the OpenDatabase method.
Second one:
The read lock is being released without being held.
This one occurs at LiteDB.Engine.LockService.ExtiTransaction()
followin the stack trace, it happens when the TransactionService.Finalize() is called upon disposing it within ReleaseTransaction methon in Transaction Monitor.
Code to Reproduce
This is the part of a big solution that access the litedb a lot, no simple example to reproduce
Expected behavior
No exception upon file write/read.
Screenshots/Stacktrace
Additional context
Any ideas how to work around this?
Would using the LockRecursionPolicy.SupportsRecursion help for the first issue?