Discussions

EJB design: How should application level locking be implemented?

  1. 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 (could be read lock or write 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 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.

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

     

  2. If your resources are other database tables, probably you may explore:

    1. Hibernate's optimistic locking features

    2. Set appropriate database connection isolation levels to explicitly acquire write_lock.

    3. Programmatically acquire write_lock for concerned table(s).