Hey,
Thank you for this great library!
When using a SqlDistributedLock from DistributedLock.SqlServer, scoped to a transaction, it seems that the lock is released before the transaction is commited/rollbacked (sp_releaseapplock executed explicitly before transaction commit)
Wasn't expecting that and thought that this is by design, but then I looked through the code and found the following:
|
var canSkipExplicitRelease = |
|
this._transactionScoped && (!this.Connection.IsExernallyOwned || !this.Connection.CanExecuteQueries); |
If we're in the transaction scoped scenario and the transaction hasn't been commited (connection is externally owned and still open) we'll have
true && (!true || !true) -> true && (false || false) -> true && false -> false
I'm not entirely sure of the meaning behind those properties, but shouldn't it match the comment above this piece of code and be like:
var canSkipExplicitRelease =
this._transactionScoped || (!this.Connection.IsExernallyOwned || !this.Connection.CanExecuteQueries);
Thanks!
Hey,
Thank you for this great library!
When using a SqlDistributedLock from DistributedLock.SqlServer, scoped to a transaction, it seems that the lock is released before the transaction is commited/rollbacked (
sp_releaseapplockexecuted explicitly before transaction commit)Wasn't expecting that and thought that this is by design, but then I looked through the code and found the following:
DistributedLock/src/DistributedLock.Core/Internal/Data/DedicatedConnectionOrTransactionDbDistributedLock.cs
Lines 218 to 219 in 3da3eaf
If we're in the transaction scoped scenario and the transaction hasn't been commited (connection is externally owned and still open) we'll have
true && (!true || !true) -> true && (false || false) -> true && false -> falseI'm not entirely sure of the meaning behind those properties, but shouldn't it match the comment above this piece of code and be like:
Thanks!