EJB command group

The EJB command group for the AdminTask object provides commands we can use to manipulate enterprise beans.

removeAutomaticEJBTimers

Applications or modules use annotations or XML to instruct the application server to automatically create EJB timers.

Automatically created timers are persisted in the scheduler instance associated with the server that the application or module is running on at the moment the automatic EJB timer is created. Schedules are configured on a per server basis, and thus it is possible for each server in your topology to use a unique scheduler instance. In this case, the scheduler instance specific to each server supports the EJB timers running in that server.

Each scheduler instance is associated with a set of database tables. If we have multiple scheduler instances, configure each scheduler instance with a unique prefix to ensure the instance maps to a unique set of database tables.

When the application or module that requested the automatic EJB timers are removed from a server, the automatic EJB timers must be removed from the corresponding scheduler instance. If the application or module was installed on multiple servers, and each of those servers used a unique scheduler instance, then the timers must be removed from each of those scheduler instances. In other words, automatically created EJB timers are removed on a per server basis.

In some cases, the removal or update of the application or module results in the removal of the automatically created EJB timers from the scheduler instance. In this scenario, no user action is required.

However, in other cases, the removal, or update of the application or module does not result in the removal of the automatically created EJB timers from the scheduler instance. In this case, we must manually remove the EJB timers using the removeAutomaticEJBTimers command.

The command is only supported in a connected mode. In a network deployment topology, the deployment manager, NodeAgent, and the managed server containing the scheduler instance must all be running. In a base topology, the stand-alone server must be running.

In a Rational Application Developer loose configuration scenario, we must manually remove your automatically created EJB timers. Also, programmatically created EJB timers, which are not the same as automatically created EJB timers, are not automatically removed or removed by this command.

In a network deployment topology, when a single module is only installed on a subset of the servers in the topology, the automatically created timers associated with that module must be removed from the scheduler instance(s) associated with that subset of servers only. A scheduler instance corresponding to a server that does not have the module installed on it does not need to be cleaned up.

Target Object: None

Required parameters:

-appName

The name of the application that requested the automatically created EJB timers we want to remove. (String, required)

-serverName

The name of the server that runs the application or module containing the automatically created EJB timers we want to remove. This parameter represents the logical name of an application server, not a host name. (String, required)

Optional parameters:

-schedulerJNDIName

This parameter represents the JNDI name of the scheduler instance that persists the automatically created EJB timers we want to remove.

A server instance is always configured to use a particular scheduler instance to support automatically created EJB timers. We can explicitly configure which scheduler instance is used, or we can choose to not explicitly configure a scheduler instance. In the latter case a default scheduler instance is used.

If the scheduler instance containing the automatically created EJB timers we want to remove is the same scheduler instance that is currently configured for the server, then we can omit this parameter. In this case, the command examines the configuration, discovers the scheduler instance that is currently configured, and uses that.

However, if the scheduler instance that is currently configured is not the one containing the EJB timers we want to remove, then specify the JNDI name of the scheduler instance that does contain these timers. (String, optional)

-nodeName

The name of the node containing the server. (String, required)

-moduleName

The name of the module that requested the automatically created EJB timers we want to remove. To remove all automatically created timers in the application, regardless of which module they are defined in, then this parameter is omitted. Only specified when we want to remove the automatically created timers requested by one module in the application, but not the timers requested by another module in the same application. (String, optional)

Return value: None

The following information helps to determine when this command is needed:

• WebSphere Application Server attempts to remove automatically created EJB timers when all the following conditions are met:

  • One of the following actions is performed:
    • Application uninstallation
    • Application update
    • Module uninstallation
    • Module update

  • The action was performed in a connected mode (not wsadmin -conntype none).

  • The needed servers were running at the time of the action.

    • For a network deployment topology, the deployment manager, node agent, and managed server containing the automatically created EJB timers were all running.

    • For a base topology, the stand-alone server was running.

  • The correct follow-up action was performed.

    • For a network deployment topology, you save the changes and synchronize them to the node agent. If we save the changes but do not synchronize them, then the automatically created EJB timers are not removed. The automatically created EJB timers are only removed during the sync processing.

    • For a base topology, you save the changes.

  • The database supporting the scheduler instance was running.

• WAS does not remove automatically created EJB timers when any of the following conditions occur:

  • Any action is performed other than an update or uninstallation of an application or module.

  • The action (even if it is an application/module uninstallation/update) was performed in disconnected mode.

  • The needed servers were not running.

    • For a network deployment topology, the deployment manager, node agent, or managed server was not running.

    • For a base topology, the stand-alone server was not running

  • The correct follow-up action was not performed.

    • For a network deployment topology, either the save or synchronize was not performed.

    • For a base topology, the save was not performed.

  • The database supporting the scheduler instance was not running.

If WAS encounters an error when attempting to remove automatically created EJB timers from a server, then a warning is written to log file.

If an error occurs, or if the application server did not attempt to remove automatically created EJB timers, or if we are not sure if the automatically created EJB timers were removed, manually issue the removeAutomaticEJBTimers command to ensure that the automatically created EJB timers are removed. If the automatically created timers were actually removed from the scheduler instance, running the command is unnecessary, but does no harm.

If we are running in a clustered environment, and your cluster contains multiple nodes, and each of those nodes contains a server that maps to the same cluster level scheduler instance, then the automatically created timers only must be removed from one of the servers. This is because the shared scheduler instance is updated, and all servers using that shared scheduler instance see the change.

As a result, if a server in one node is not running and we receive a log warning that the automatic timers could not be removed from it, but you know that server shares a cluster-level scheduler instance with a server in a different node that was successfully cleared, then no user action is required because the shared scheduler instance has already been updated.

The same is true when there are multiple servers in a cluster, and they are all part of the same node, and share a single cluster-level scheduler instance, and one or more of those cluster members are not running. In this case, the application server issues a log warning that the automatic timers could not be removed from those servers. However if we know that they share a common scheduler instance, and one of the cluster members was successfully cleared, then no user action is required because the shared scheduler instance has already been updated.

If we are running in a network deployment topology and have multiple servers, the type of scheduler used (default versus custom configured) has an impact on performance in regards to scheduler cleanup. The default EJBContainer scheduler is unique per server. If we are using the default EJBContainer scheduler instance, and we have five servers, this means we have five unique scheduler instances, and the automatic timers must be removed from all five of them when the application is updated or removed. However, if we are using a single shared, custom configured scheduler instance, then the automatic timers must only be removed once, from that one scheduler instance.

Example 1

Topology:

• Deployment manager running on workstation A.
• NodeAgent running on workstation B. The node is called Node01.
• Managed server server1 running on workstation C.
• Managed server server2 running on workstation D.
• Security is enabled.
• server2 is currently configured to use the same scheduler instance containing the timers.

Background:

The testApp application was uninstalled in a connected mode from the administrative console. You want to remove all the automatically created timers in the application, regardless of which module requested them.

The deployment manager, node agent, and server1 servers were running, and the automatic EJB timers were removed from server1. However, server2 was not running, and so the automatic EJB timers were not removed from server2.

Now, we must manually remove the automatic EJB timers from server2.

Action:

• Use Jacl, from a connected wsadmin session in the deployment manager enter the following line of code:

  $AdminTask removeAutomaticEJBTimers "-appName testApp -serverName server2 -nodeName Node01"
  

• Use Jython, from a connected wsadmin session in the deployment manager enter the following line of code:

  AdminTask.removeAutomaticEJBTimers('-appName testApp -serverName server2 -nodeName Node01')
  

Example 2

Topology:

• Stand-alone server1 running on workstation A. The node is called Node01.
• Administrative security is disabled.
• server1 was configured to use scheduler instance jndi/sched_1 when the automatic EJB timers were created. However, server1 is currently configured to use scheduler instance jndi/sched_2.

Background:

The module, mod1, from application, testApp, was uninstalled, but because server1 was configured to use the jndi/sched_2 instance at the moment of uninstallation, the automatic EJB timers were not removed from scheduler instance jndi/sched_1.

Now, we must manually remove the automatic EJB timers from the jndi/sched_1 scheduler instance on server1.

The application contains modules, mod1 and mod2. Both of these modules requested automatically created EJB timers. The mod2 module is still installed, and you still need the automatically created EJB timers it requested. You only want to remove the automatically created EJB timers requested by mod1.

Action:

• Use Jacl, from a connected wsadmin session in the stand-alone server enter the following line of code:

  $AdminTask removeAutomaticEJBTimers "-appName testApp -moduleName mod1 -serverName server1 -nodeName Node01 -schedulerJNDIName jndi/sched_1"
  

• Use Jython, from a connected wsadmin session in the stand-alone server enter the following line of code:

  AdminTask.removeAutomaticEJBTimers('-appName testApp -moduleName mod1 -serverName server1 -nodeName Node01 -schedulerJNDIName jndi/sched_1')