Administer > Overview of administering a WebSphere Commerce site > Administration Console > Scheduler > Jobs

Scheduler configuration parameters

You can change scheduler parameters to control behavior such as...

• expiry time
• waiting time between checks for jobs
• number of threads to allocate to an application type

Scheduler configuration parameters are stored in the WebSphere Commerce configuration file.

Example parameters...

<component compClassName="com.ibm.commerce.scheduler.SchedulerComm" 
           enable="true" 
           name="Scheduler"> 

   
<property autoClean="off" 
              broadcastExpireTime="1800" 
              contextSetName="Authoring" 
              cycleTime="600" 
              display="false"/> 

</component> 

Scheduler properties

The scheduler properties are defined in the <properties> element inside the scheduler component element. The attributes are:

autoclean

If set to "on", the SCHSTATUS entries that the scheduler creates will be deleted when the job completes. If set to "off" these entries will stay in the database until the CleanJob command is called. The default value is "off".

broadcastExpireTime

Sets the lifespan (in seconds) of a broadcast job.

contextSetName

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

cycleTime

Sets the maximum time, in seconds, that the scheduler can idle before waking up to check if there are jobs waiting to run.

display

IBM Internal use only.

In contrast, the scheduler configuration parameters in WebSphere Commerce v6 were stored in the WebSphere Commerce configuration file. An example of the scheduler configuration parameters in this file are shown in the XML sample below:

<component compClassName="com.ibm.commerce.scheduler.SchedulerComm" 
           enable="true" 
           name="Scheduler"> 

   
<property autoClean="off" broadcastExpireTime="1800" contextSetName="Authoring" cycleTime="600" display="false"> 
       
<applicationType applicationName="default" maxNumofThreads="10"/> 
       
<applicationType applicationName="broadcast" maxNumofThreads="10"/> 
       
<applicationType applicationName="auction" maxNumofThreads="10"/> 
       
<applicationType applicationName="inventory" maxNumofThreads="10"/> 
   
</property> 
</component>

The work manager is used in WebSphere Commerce v7 for WebSphere Commerce Scheduler, MQ Listener and other components, instead of spawning Java threads. By leveraging the work manager, administrators use a consistent interface to manage these additional asynchronous processes, while WebSphere Application Server now manages these additional processes that are part of a J2EE 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 v7, 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.

The scheduler application types are modified using the WebSphere Application Server Administration Console:

1. Open the WebSphere Application Server Administration Console.

2. Navigate to Work manager > Work manager name.

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

4. Save the changes.

• Create work managers for custom thread groups
  Work managers can be created manually for customization using the WebSphere Application Server Administration Console. If you expect many scheduler jobs of the same application type, you should create a separate work manager to limit the number of threads handling these scheduler jobs. Otherwise, having many scheduler jobs of the same type can create bottleneck for other scheduler jobs.

Related concepts

Performance enhancements

WebSphere Application Server considerations

Related tasks

Create work managers for custom thread groups

Related information

Work managers

+

Search Tips   |   Advanced Search