Locking in TIBCO BusinessEvents
The goal of locking is to ensure consistency across concurrent RTCs.
If one RTC has a rule condition that includes a concept, and another RTC updates that concept, then the results could be undefined. Or if two RTCs update the same object at the same time, then different properties of the object could be set by different threads leaving an overall object with incorrect property values.
Locking protects the thread of executing when multiple threads in an agent can cause conflicts by trying to write to the same concept at the same time during concurrent RTCs. The same type of issue can occur across inference agents operating concurrently.
Locking is also necessary to ensure that stale data – data that has been modified in another RTC but not yet written to cache – is not read.
Lock operations do not operate a lock on the object you want to protect itself. They set a common flag that represents a lock — it is up to the developer to ensure that all accesses and updates to a concept subject to locking are enforced, and that only necessary concepts (including concepts that are written to as well as those used in conditions) are locked
The typical lock operation is: in the event preprocessor set the lock, using any unique string as a key. For example, you can use the object extId as the lock string. If a preprocessor cannot acquire the lock (because another event’s preprocessor has acquired it) then it waits until either the lock is released OR some timeout occurs.
Locking code needs to be prepared carefully. If two events try lock(A) then lock(B) and lock(B) then lock(A) respectively, then a situation can arise where both are waiting on each other’s thread. Locking should be used sparingly.
With cache plus memory OM, the need for locks is greater than with cache only, because each agent’s Rete network must be synchronized for changes made in all other agents’ Rete networks.