How to cancel or remove Persistent EJBTimers

When we use persistent EJBTimer with @schedule and persistent=true, deploy it to cluster and then we change the actual schedule within @Schedule and re-deploy to the cluster, does the original schedule get replaced with the new one ( removed and added with new parameters ), or both the schedules remain active ( keeping in mind the persistent=true is set )

This is what I have read so far - Each scheduler instance has a unique jndi name and @schedule automatically creates a timer through application deployment so it would be better to remove the automatic created EJBTimer or cancel the original schedule to avoid trouble. But I don't know how to cancel the original schedule programmatically or would that need to be done by the websphere admins, if both the original and changed schedules remain active

Also from this document, the removeAutomaticEJBTimers command is used to remove timers from a specified scheduler, but that also seems in the area of a websphere admin, not a developer.

How can a developer programmatically cancel an automatic EJBTimer created by using @Schedule annotation?

I am using Java EE 6 with Websphere 8.5 and EJB 3.1.

Solution

See this page Creating timers using the EJB timer service

The application server automatically removes persistent automatic timers from the database when you uninstall the application while the server is running. If the application server is not running, you must manually delete the automatic timers from the database. Additionally, if you add, remove, or change the metadata for automatic timers while the server is not running, you must manually delete the automatic timers.

I have the following class:

@Stateless
@LocalBean
public class HelloBean {
    @Schedule(persistent=true, minute="*", hour="*", info="myTimer")
    public void printHello() {
        System.out.println("### hello");
    }

}

When I install it to the server, I can find related automatic timer:

C:\IBM\WebSphere\AppServer85\profiles\AppSrv02\bin>findEJBTimers.bat server1 -all
ADMU0116I: Tool information is being logged in file C:\IBM\WebSphere\AppServer85\profiles\AppSrv02\logs\server1\EJBTimers.log
ADMU0128I: Starting tool with the AppSrv02 profile
ADMU3100I: Reading configuration for server: server1
EJB timer : 3     Expiration: 2/14/15 12:39 PM     Calendar
   EJB    : ScheduleTestEAR, ScheduleTest.jar, HelloBean
   Info   : myTimer
   Automatic timer with timout method: printHello
Calendar expression: [start=null, end=null, timezone=null, seconds="0",
           minutes="*", hours="*", dayOfMonth="*", month="*", dayOfWeek="*", year="*"]
1 EJB timer tasks found

After uninstalling application, the timer is removed:

C:\IBM\WebSphere\AppServer85\profiles\AppSrv02\bin>findEJBTimers.bat server1 -all
ADMU0116I: Tool information is being logged in file
           C:\IBM\WebSphere\AppServer85\profiles\AppSrv02\logs\server1\EJBTimers.log
ADMU0128I: Starting tool with the AppSrv02 profile
ADMU3100I: Reading configuration for server: server1
0 EJB timer tasks found

I don't know how you are 'redeploying' your applications, but looks like your process is incorrect. As in normal install/uninstall/update process automatic timers are correctly removed.

UPDATE
On the same page you have info regarding ND environment:

Automatic persistent timers are removed from their persistent store when their containing module or application is uninstalled. Therefore, do not update applications that use automatic persistent timers with the Rollout Update feature. Doing so uninstalls and reinstalls the application while the cluster is still operational, which might cause failure in the following cases:

If a timer running in another cluster member activates after the database entry is removed and before the database entry is recreated, then the timer fails. In this case, a com.ibm.websphere.scheduler.TaskPending exception is written to the First Failure Data Capture (FFDC), along with the SCHD0057W message, indicating that the task information in the database has been changed or canceled.

If the timer activates on a cluster member that has not been updated after the timer data in the database has been updated, then the timer might fail or cause other failures if the new timer information is not compatible with the old application code still running in the cluster member.