Lock Processing Example Flow
The following example demonstrates common locking requirements.
The example uses these features:
- Cache plus memory mode (requires more locking than cache only mode)
- Cache-aside and backing store (backing store not shown).
Two agents receive messages that require changes to one Customer instance.
Note that event preprocessors are multi-threaded (see Event Preprocessors for more details).
- A message comes into a channel on Agent A: a change to a customer address. TIBCO BusinessEvents dequeues the message from the queue, deserializes the message to an event, and calls the event preprocessor function. The preprocessor acquires a lock using the customer’s
extID as the key:
Cluster.DataGrid.Lock(Customer@extId, -1, false);
This function causes the thread to stop until it gets the lock. In this example, the thread gets the lock.
- Only one thread handles the RTC. (Concurrent RTC is not used in this example.) Other event preprocessor threads go into a queue. During the RTC, a rule executes and modifies the customer address. After RTC completes, the post RTC phase begins: the address change is written to L1 cache, the cluster cache, and the backing store in parallel. Messages arising from the RTC are sent.
- After the post RTC actions are completed, the lock is released.
Note: If the write-behind option is used instead of cache-aside, the lock is released after changes are written to cache.
Subscription preprocessor activities run on a different thread from event preprocessor activities. One subscription task handles all the changes to the objects from one regular RTC and executes as many preprocessors as there are modified objects. (The subscription preprocessor is assigned to an entity in the CDD file Domain Object Override Settings area.)
- Agent A sends a change notification to all other agents that have subscribed to cluster notifications for this object. Agent B receives the notification, and calls the subscription preprocessor function. It contains the same function shown in step 1 above. It uses the same locking string. Agent B acquires the lock (that is the function returns true). The agent updates the Rete network with the changes (using a “subscription RTC”). It will release the lock when the subscription RTC is complete.
- While the subscription update thread holds the lock, Agent B receives a message with a change to the same customer’s address and attempts to acquire a lock, but it is blocked (that is, the function returns
false).
When the subscription preprocessor releases the lock, then Agent B’s event preprocessor can acquire it (depending on timeout behavior) and assert the event to the Rete network.
Depending on timing, either an event preprocessor or a subscription preprocessor could be holding the lock.