IBM Support

Netcool/Impact: Policy function: Synchronized behaviour in a Cluster

Technical Blog Post


Netcool/Impact: Policy function: Synchronized behaviour in a Cluster


Netcool/Impact IPL Synchronized function behaviour in a Cluster

This is a brief discussion about how the Synchronized function works and how it behaves in a Clustered ImpactServer environment.

The Synchronized function operates by identifying a section of Policy code with name that, when encountered, the Policy process checks for any other threads within the ImpactServer running the same section of code.  If it encounters another thread already processing this section of code (Synchronized Block) the thread is paused until the existing Synchronized Block has completed.  This combines the multi-threaded ability of the ImpactServer with the potential need to single thread sensitive portions of Policy code.  This is covered in the documentation Synchronized statement blocks and was originally created in Impact 3 before ability to Cluster ImpactServers was available.

The Synchronized function only operates within the ImpactServer and not across a Cluster and there is the potential for two threads on separate ImpactServers within a Cluster to be running the Policy simultaneously and the Synchronized block on each would not be aware of each other and would not single thread the Policy operation encompassed by the function.

Alternate methods to ensure that the Policy is only run within the Primary ImpactServer of a Cluster:

  • The Policy is launched by a PolicyActivator Service (but this would naturally single thread the process all the time anyway).
  • The Policy is launched by an EventReader with EventLocking enabled against field(s) pertinent for the specific events to be targeted by this Policy (but this would single thread any events with matching field values, depending upon how encompassing are the fields employed in the EventLocking Expression).

Both methods will ensure operation on only the Primary ImpactServer of the Cluster and the latter does allow for multi-threading, provided the field value combination employed in the EventLocking Expression is unique enough to allow for each captured row to be treated individually and avoid single threading of the Policy process for all events.




Subscribe and follow us for all the latest information directly on your social feeds:











Check out all our other posts and updates:

Academy Blogs:
Academy Videos:
Academy Google+:
Academy Twitter :




[{"Business Unit":{"code":"BU004","label":"Hybrid Cloud"},"Product":{"code":"","label":""},"Component":"","Platform":[{"code":"","label":""}],"Version":"","Edition":""}]