Scheduler configuration parameters

We can change scheduler parameters to control behavior. We can control behaviors such as expiry time, waiting time between checks for jobs, and the number of threads to allocate to an application type.

Scheduler configuration properties

The general scheduler configuration parameters are stored in the WebSphere Commerce configuration file. Examples of the scheduler configuration parameters within this file are shown in the following XML sample:

<component 
  compClassName="com.ibm.commerce.scheduler.SchedulerComm" 
  enable="true" name="Scheduler"> 
  <property autoClean="off" broadcastExpireTime="1800" 
    contextSetName="Authoring" cycleTime="600" display="false"/> 
</component> 

The scheduler properties that are defined within the <properties/> element within the scheduler <component></component> element include the following properties:

autoclean

When the value of this property is set to "on", the entries within the SCHSTATUS database table that the scheduler creates are deleted when the jobs complete successfully. The entries are not deleted when the jobs fail. When this property is set to "off", these entries remain within the database table until the CleanJob command is called. Default is "off".

broadcastExpireTime

This property sets the lifespan (in seconds) of a broadcast job.

contextSetName

The identifier of the business context set to use when a scheduler job runs.

cycleTime

Sets the maximum time (in seconds) that the schedule can idle before the scheduler checks for waiting jobs.

display

For internal usage only.

We can also set the following property for the scheduler:

transactionTimeout

Sets a timeout for the scheduler component. For example:

<component 
  compClassName="com.ibm.commerce.scheduler.SchedulerComm" 
  enable="true" name="Scheduler">
  <property autoClean="off" broadcastExpireTime="1800" transactionTimeout="600"
    conntextSetName="Authoring" cycleTime="600" display="false"/>
</component>

The scheduler transaction timeout is constrained by the value of the maximum transaction timeout that is set within the WebSphere Application Server Administration Console. Within the Administration Console, we can disable the maximum transaction timeout by specifying a value of 0. Then, set the transaction lifetime timeout to the timeout value used for non-scheduler requests. For more information about transaction service settings, see Transaction service settings.

Work manager for the scheduler

The work manager is used for the WebSphere Commerce Scheduler, IBM MQ Listener, and other components, instead of creating Java threads. By using the work manager, administrators can use a consistent interface to manage these additional asynchronous processes. The WebSphere Application Server manages these additional processes, which are part of a Java Platform, Enterprise Edition application.

The WebSphere Commerce ThreadManagement component uses the factory approach to create the correct thread management implementation according to the current environment.

In WebSphere Commerce, the applicationType is replaced by the Name property of a work manager, and the maxNumofThreads is replaced by the Maximum number of threads property of a work manager. We can modify the scheduler application types within the WebSphere Application Server Administration Console:

1. Open the WebSphere Application Server administration console.

2. Expand Resources > Asynchronous beans > Work manager. Click Work managers > Work manager name.

3. In the Thread pool properties section, enter the value for the Maximum number of threads property.

4. Save our changes.

• Creating work managers for custom thread groups
  To create work managers, use the WebSphere Application Server Administration Console. If you expect many scheduler jobs of the same application type, create a separate work manager to limit the number of threads that handle these scheduler jobs. Otherwise, the existence of many scheduler jobs of the same type can create a bottleneck for other scheduler jobs.

Related concepts
Application server considerations
Jobs

Related tasks
Creating work managers for custom thread groups

Related information:

Work managers