Clarification - when to create a lock?

[madelson]

Clarification - when to create a lock?

[madelson]

Thanks for your interest in the library!

How often should I be creating a lock?

The lock objects in DistributedLock are very light-weight and are stateless (unless you construct with a specific SqlConnection instead of a connection string). Therefore, you can construct them as frequently or as infrequently as you'd like; do whatever is convenient for the design of your code.

Does a new SqlDistributedLock require a separate sqlserver connection?

If you pass a SqlConnection or SqlTransaction to the lock constructor, then it will use that specific connection/transaction for all locking requests. Because SqlConnection/SqlTransaction are not thread-safe, then that lock instance won't be thread-safe either.

However, the more typical approach (which is what your code sample appears to do) is to pass a connection string. With this approach, each acquire will open a new SqlConnection under the hood (except with multiplexing; see below). Unless your connection string explicitly disables connection pooling, most of the time this will draw an existing connection from the .NET connection pool rather than actually creating a new one. When the lock handle is released, the underlying connection is closed (released back to the pool).

I should be using OptimisticConnectionMultiplexing

The main resource risk with SqlDistributedLocks is that holding/waiting for many locks simultaneously occupies many connections. This can lead to connection pool exhaustion (if this happens, you'll see specific error messages thrown that relate to it). The default connection pool size is 100 per unique connection string; so one quick fix that works for most applications is to just up the pool size.

OptimisticConnectionMultiplexing lets you scale even further in some scenarios by allowing one connection to service multiple lock requests. This works best when you TryAcquire locks with zero timeout or with a small timeout or when contention is very low (hence "optimistic"), since fundamentally one connection can only block waiting on one lock at a time.

But I need the Azure strategy, because sometimes one call to the method may run for an hour or more. Would it be possible to combine the two strategies?

If you need the Azure strategy, I would recommend sticking with that. I'm currently working on a 2.0 release of the library, and one of the new features is that optimistic multiplexing and keepalive are both on by default. So once 2.0 comes out you can get this for free.

Until then, I would suggest that you continue using Azure and just bump up the connection pool size if you are experiencing connection pool exhaustion.

[bokmadsen]

Great, thanks for getting back. I'll stick with Azure strategy and try to bump the connection pool