Not logged in | Login
The Scheduler BC is not aware of multiple instances in a cluster. When implemented in a clustered environment, the BC works in the same way as in a standard environment, which means that all instances of the BC in a cluster function independently of one another instead of sharing the work load. Each time the Scheduler BC is triggered in a cluster, each server instance in the cluster processes the request, which results in multiple responses to each request instead of just one.
To use the Scheduler BC in a clustered environment, you need to configure a way for the receiving provider to treat the received trigger message such that multiple instances running at the same time do not change the result. For example, when using the Scheduler BC in conjunction with the Database BC to insert rows into a table, using a unique field from the message as a primary key would prevent multiple rows being inserted for one request. The Scheduler BC exposes an intended trigger date (accessed through the normalized message property org.glassfish.openesb.scheduler.inbound.date) that could be used as a primary key. Triggers are described under Creating Simple Triggers. The date format is described under Using the Scheduler Control and Triggers Wizard. You can use the substring-before XPath function in a business process to extract the timestamp, along with logic to catch any unique key violations. The substring-before function is documented under BPEL Mapper String Functions.
The Scheduler BC is dependent on the following shared libraries: