The DistributedLock.Oracle package offers distributed synchronization primitives based on Oracle's DBMS_LOCK package. For example:
var @lock = new OracleDistributedLock("MyLockName", connectionString);
using (@lock.Acquire())
{
// I have the lock
}
Because the library uses Oracle's DBMS_LOCK package under the hood, you may need to permission your user to that package. If you encounter an error like identifier 'SYS.DBMS_LOCK' must be declared ORA-06550
, configure your Oracle user like so:
connect as sys
grant execute on SYS.DBMS_LOCK to someuser;
See this StackOverflow question for more info.
- The
OracleDistributedLock
class implements theIDistributedLock
interface. - The
OracleDistributedReaderWriterLock
class implements theIDistributedUpgradeableReaderWriterLock
interface. - The
OracleDistributedSynchronizationProvider
class implements theIDistributedLockProvider
andIDistributedUpgradeableReaderWriterLockProvider
interfaces.
Oracle-based locks locks can be constructed with a connectionString or an IDbConnection
as a means of connecting to the database. In most cases, using a connectionString is preferred because it allows for the library to efficiently multiplex connections under the hood and eliminates the risk that the passed-in IDbConnection
gets used in a way that disrupts the locking process. NOTE that since IDbConnection
objects are not thread-safe, lock objects constructed with them can only be used by one thread at a time.
The classes in this package support async operations per the common distributed lock and ADO.NET interfaces. However, as of 2021-12-14, the Oracle .NET client libraries do not support true async IO. Therefore, if you are using the Oracle-based implementation you might get slightly better performance out of the synchronous APIs (e. g. OracleDistributedLock.Acquire()
instead of OracleDistributedLock.AcquireAsync()
).
In addition to specifying the key
, several tuning options are available for connectionString
-based locks:
KeepaliveCadence
allows you to have the implementation periodically issue a cheap query on a connection holding a lock. This helps in configurations which are set up to aggressively kill idle connections. Defaults to OFF (Timeout.InfiniteTimeSpan
).UseMultiplexing
allows the implementation to re-use connections under the hood to hold multiple locks under certain scenarios, leading to lower resource consumption. This behavior defaults to ON; you should not disable it unless you suspect that it is causing issues for you (please file an issue here if so!).