Configuring Locking Operation on Retry When Receiving/Retrieving a Message

Locking is enabled by default. Disabling it will help to avoid database row lock contention when dealing with high volumes of correlation and event handlers. It might introduce delays in processing messages when a message is being delivered at the exact same time as a corresponding receiver task.

To change the setting of locking and other related properties that are described below, use ActiveMatrix Administrator to update the Java Virtual Machine (JVM) configuration for the ActiveMatrix BPM nodes, as explained in the TIBCO ActiveMatrix BPM SOA Administration guide. You need to add (and set) the relevant properties on the JVM Configuration page within the Configuration tab. When you have done this, the properties are added to each BPM node's .tra file.

To disable locking system-wide set com.tibco.bx.lockOperation to false. If locking is disabled then a background job that checks the messages that have not been claimed yet will be started. To control its execution frequency set com.tibco.bx.bpel.bg.unclaimedMsgProcessor.interval (default is 30 minutes, lowest possible value is 1 minute - P1). The com.tibco.bx.bpel.bg.unclaimedMsgProcessor.numMsgs property controls a maximum number of messages that a job will pick up per execution (default is 500, minimum 50).

If system-wide locking is enabled then com.tibco.bx.lockPerOperation=true can be used to enable finer-grained control by using the following properties:

  • module level: com.tibco.bx.lockOperation.ModuleName - if this property is defined (whether it is true or false) then the operation level property is not going to take effect.
  • operation level: com.tibco.bx.lockOperation.ModuleName.PortType.OperationName (where PortType is in the form of {NamespaceURI}localPart).
Important: The background job will not be running when system-wide locking is enabled, which introduces a possibility of an unclaimed message and a stuck instance in case of concurrent processing as mentioned above.