ESQL shared row locking and ATOMIC blocks

You can use ESQL shared rows in a message flow to share data between threads, so that all threads are able to read and update data written by other threads. You can also use ESQL shared rows in a message flow to share data across time, which means that messages passing through a flow can save data for future access.

About this task

One example of using ESQL shared rows is the caching of database contents in shared variables for performance reasons. In this scenario, which uses both types of data sharing, the first thread loads the data into the cache for use by all threads, and from that point on no database accesses are required.

When you are using shared variables, you must ensure that access to the data is synchronized so that you can avoid problems caused by multiple threads accessing the same data. For example, if database caching consists of more than one element, you need to block threads from trying to read the data while it is being updated.

IBM® App Connect Enterprise supports a shared variable implementation, in which the integration server has two levels of locking to ensure that collisions can be prevented. The first level is at the shared variable itself, and the second level is the ATOMIC keyword in ESQL, which you can use to synchronize flow threads. Both of these mechanisms use read-write locks instead of mutexes, to allow better scaling in multi-threaded solutions.

Read-write locks provide the following benefits when used with shared rows:

  1. The ability of multiple readers to read data without blocking, which makes the caching scenario scale better and can improve performance.
  2. The ability of a single writer to block all readers, which makes it possible to load the cache without readers seeing partial updates. This approach can be beneficial in terms of reliability.
When a thread is able to take multiple locks (both read and write), it is possible for each of two threads to be holding a lock while waiting for the lock held by the other thread. The following example involves two threads taking locks in the opposite order, leading to a deadlock: 

thread 1 takes write lock A
thread 2 takes write lock B
thread 1 tries to take read lock B and blocks because thread 2 is holding the write lock
thread 2 tries to take read lock A and blocks because thread 1 is holding the write lock

As these deadlocks can be difficult to detect, the shared variable locking code takes steps to prevent them from occurring, restricting which locks can be taken when other locks are held. For example, calling PROPAGATE while in an ATOMIC block will result in a BIP2526 exception being thrown.

For examples of using shared rows with and without ATOMIC blocks, see the following topics:
For additional information about using ESQL, see the following topics: