+

Search Tips   |   Advanced Search

Configure a timer service

We can configure and manage the EJB timer service for a specific EJB container.

WebSphere Application Server implements the EJB Timer Service. Based on the business needs, we can use persistent timers or non-persistent timers. Persistent timers are helpful if you are creating a timer for a time-based event that requires assurance of timer existence beyond the life cycle of the server to persist through server shutdowns and restarts. Previously started persistent timers automatically start when the server starts, and they require a database instance.

Non-persistent timers do not use a data store and are canceled when the application server is stopped or fails to remain in an active state. Non-persistent timers exist only on the server where the timer is created.

Both persistent and non-persistent timers require a work manager. Persistent timers use the work manager used by the scheduler service. Non-persistent timers use the server default work manager by default, but can be configured to use another work manager using EJB timer scripting. Non-persistent timers do not use the scheduler service.

We can configure and manage the EJB timer service for persistent and non-persistent timers in the console. The configuration for persistent and non-persistent timers is not mutually exclusive. Your application might contain both persistent and non-persistent timers.

  1. Click Servers > Application servers > server_name > EJB Container settings > EJB timer service settings.

  2. Configure the persistent EJB timer support.

  3. To use the internal, or pre-configured, scheduler instance, select Use internal EJB timer service scheduler instance. If we choose not to change the default settings, this instance for the scheduler is associated with an Apache Derby database. If we choose to customize the pre-configured instance...

    1. To change the data source, enter the Data source JNDI name. We can use any supported database, such as DB2 or Oracle.

    2. Enter the chosen Data source alias.

    3. Enter the chosen Table prefix to have several server processes use the same database, but different tables.

    4. Enter a Poll interval value in milliseconds.

    5. If we want more timers to run concurrently, enter a new value for Number of timer threads.
    For more details, see information about timer service settings.

  4. To configure our own scheduler instance instead of using the pre-configured internal one, select Use custom scheduler instance. We might want to use our own instance to:

    • Change scheduler service configuration options not available for customization on this panel

    • Keep EJB timer tasks in the same database tables as the other tasks

    • Have a single scheduler instance handle all the EJB timers in a cluster. This way, an ejbTimer task created on one cluster member can run on a different cluster member.

    To use our own instance, you must:

    1. Configure a scheduler instance through the scheduler service GUI. See the using schedulers documentation for information about how to do this.

    2. Select the Scheduler JNDI name from the list.

  5. Configure the non-persistent timer support. Support for non-persistent timers is configured in addition to (not instead of) support for persistent timers.

    1. Enter the chosen Maximum number of retries.

    2. Enter the chosen Time interval between retries.

    3. Select the Share thread pool configured for persistent timers or the Create a separate thread pool for non-persistent timers option. If we choose the Create a separate thread pool for non-persistent timers option, enter the chosen Number of timer threads.

  6. Optional: Configure data caching for the EJB timers. Caching allows the application server to reuse timer data without having to query the database each time that data is required. See the topic on caching data for a timer service for information on configuring this feature.

  7. Click Apply.

  8. Click OK.


Subtopics


Related tasks

  • Use schedulers