WAS v8.5 > Administer applications and their environment > Welcome to administering EJB applications

Configure a timer service

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

WebSphere Application Server implements the EJB Timer Service. We can use persistent timers or non-persistent timers. Persistent timers 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 manage the EJB timer service for persistent and non-persistent timers in the dmgr console. The configuration for persistent and non-persistent timers is not mutually exclusive. Applications can contain both persistent and non-persistent timers.

  1. Configure the persistent EJB timer support...

      Servers | Application servers | server_name | EJB Container settings | EJB timer service settings

  2. To use the internal, or pre-configured, scheduler instance, select...

      Use internal EJB timer service scheduler instance

    With the default settings, the instance for the scheduler is associated with an Apache Derby database.

    Timer service settings...

    1. Set Data source JNDI name. We can use any supported database, such as DB2 or Oracle.

    2. Set Data source alias

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

    4. Poll interval value in milliseconds.

    5. For more timers to run concurrently, set Number of timer threads.

  3. To configure our own scheduler instance instead of using the pre-configured internal one, select...

      Use custom scheduler instance

    You 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 your 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...

    1. Configure a scheduler instance through the scheduler service graphical user interface.

    2. Select your Scheduler JNDI name from the list.

  4. 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 your chosen Maximum number of retries.

    2. Enter your 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 you choose the Create a separate thread pool for non-persistent timers option, enter your chosen Number of timer threads.

  5. 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.

  6. Click Apply.

  7. Click OK.


Subtopics


Related


Use schedulers


+

Search Tips   |   Advanced Search