CODEWITHSUNDEEP
locking
Andy Dufresne
Andy Dufresne

Reputation: 6190

Implementing application level locking

We have a requirement in our application where resources need to be locked before being accessed/modified to avoid concurrent operations and maintain integrity. Since there are a series of operations performed on the resource we decided to implement an application level locking concept which all the components accessing the resource will have to respect.

Note that the resource would be accessed/modified by multiple processes hence synchronization becomes an overhead. This was also one of the reasons to choose application level locking.

One of the approaches we have in mind for implementing application level locking is to insert and update entries in a database table which would have columns like resource name, lock type (would be read lock, write lock or full exclusive lock) and the information about the process which acquired the lock. We chose database table as an option since its the only component centralized to all the processes accessing the resource, but if someone could explore out other possibilities it would be helpful.

The other problem with the database approach is that the implementation has to use pessimistic locking. (Our application uses Oracle as our db server).

The intent of this question is to explore out various approaches of implementing application level locking.

Edit 1

The reason I mention that the database approach has to implement pessimistic locking is because

  1. The resources which are accessed/modified by various application components are added dynamically by users in the software. Hence it would ugly to insert their entries always in this database table also.
  2. Even if resource entries are made in this table the problem arises on when do we delete these entries?

A optimistic locking approach would have been good but I could not think about how do we implement it.

Edit 2 Adding details on the lock type I have updated the above problem statement to specify that there are 3 lock types

  1. Read Lock - Can be acquired if all the other locks are either read or write
  2. Write Exclusive Lock - Can be acquired if all the other locks are read
  3. Full Exclusive Lock - Can be acquired if there are no locks on this resource

Upvotes: 5

Views: 3570

Answers (1)

tamarintech
tamarintech

Reputation: 1992

An additional field you might consider for your database style lock is a current time. You may also consider agreeing that any operation from an application cannot take more than X amount of time.

The reasoning behind the suggestion is to prevent scenarios where a possible application crashes, loses connectivity to the database, etc and is unable to "undo" the lock. Other applications would include functionality to remove the stale lock and create a new one.

You may also want the applications to insert the column, then wait a random amount of time and then attempt to check it again. This could help reduce the possibility of applications colliding on a resource while they were waiting for the database to complete it's operations.

Upvotes: 3

Related Questions