SqlDistributedLock timeout issue?

Hi there.

Thank you for creating a cool library! Good code too…

I use it in my web app with sql azure to make sure that certain long running operations can only be run once at a time. It’s been working fine but I just had a weird case and I thought maybe you may know something about it.

I have a block like this:

using (var @lock = new SqlDistributedLock("hello", connectionString).TryAcquire())
 {
         if (@lock == null)
               return;

         await doLongRunningOperationAsync()
}

doLongRunningOperationAsync can take quite a long time and I had a case in production where 2 requests managed to both acquire the exclusive lock! The second one acquired the lock about 45 minutes after the first one had acquired the lock (it can take over an hour for this operation to complete…)

I use version 1.1.0.0 and as I understand it, when providing a connection string, an new connection and transaction will be created and the transaction will be the owner of the lock.

So it got me thinking. Maybe transactions have a timeout after which they are automatically closed? Maybe even the connection? In particular, sql azure can suffer transient issues and it is always a best practice to retry operations since they may fail because of temporary internal azure stuff.

So long story short, is it ok to use the SqlDistributedLock for long running operations???

[madelson]

@clement911 I’ve released a new 1.3 version containing a keepalive implementation. This can be used by passing in the Azure connection strategy when constructing the lock. Let me know how it works!

For the connection monitoring API, I’ve created a separate issue to track (https://github.com/madelson/DistributedLock/issues/6).

[madelson]

Glad it’s working and thanks for letting me know.