Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)

Is there a way to delete a scheduled trigger with a specific job?

I've a job which can potentially have 100+ triggers and I really don't want to delete the job and re-register all the triggers when I just have to delete 1 trigger.

I tried doing getTriggersOfJob before and after doing unscheduleJob. It doesn't remove the trigger

Thanks

unscheduleJob does remove the trigger. If it doesn't for you, something is going wrong. Perhaps a transaction problem?

What could be a transaction problem? I'm not getting any erorrs when I do add a trigger or try to delete it. Is there any debugging options that I can turn on to see what's going on?

What job store are you using? Do you have the "wrap jobs in user transaction" setting set to true? from what context are you unscheduling the job (e.g. from within a job for from inside an application action, or... ).

I'm having a similar problem. I'm calling unscheduleJob from within a StatefulJob. (The trigger is defined with a number of retries, we don't want to retry if the job succeeded).
Code:

 private void cancelTrigger(JobExecutionContext context) {
 	if (context.getTrigger().mayFireAgain()) {
 		try {
 			boolean isCancelled = context.getScheduler().unscheduleJob(context.getTrigger().getName(),
 						context.getTrigger().getGroup());
 			if (!isCancelled) {
 				log.error("error unscheduling trigger " + context.getTrigger().getFullName() + " scheduler failed to cancel");
 			}
 		} catch (SchedulerException e) {
 			log.error("error unscheduling trigger " + context.getTrigger().getFullName() + " " + e.getLocalizedMessage());
 		}
 	}
 }

Running under jboss, using the JobStoreCMT. wrapJobExecutionInUserTransaction is set to true.

No errors are reported in the log, and a stupid monitoring servlet/web page that dumps the content of the scheduler shows the triggers are gone. But some time later (minutes, not seconds or hours) the trigger is back in the web page dump.

I don't see the triggers going away from the database table at all.

I suspect a transaction issue, but I'm at a complete loss for solving it.

Is the job throwing an exception rather than exiting cleanly? That would cause a roll-back (and make the trigger re-appear).

The job has an exception handling internally, but our implementation of StatefulJob is catching it, and uses the type of exception to determine whether it should attempt to cancel the trigger or not.

I'm not seeing any JobExecutionException stack traces in the console log.

I've discovered some of my earlier information was incorrect. I'd set wrapJobExecutionInUserTransaction = true in quartz-service.xml, but that version of the file had not been deployed when jboss restarted.

I have since set it correctly and found the right setting for org.quartz.scheduler.userTransactionUrl ('UserTransaction', sigh... why can't people use standards?)

When I attempt to run this way, I'm getting

2010-01-26 15:00:03,719 WARN [R.dennis] [com.arjuna.ats.jta.logging.loggerI18N] [com.arjuna.ats.internal.jta.transaction.arjunacore.enliststarterror] [com.arjuna.ats.internal.jta.transaction.arjunacore.enliststarterror] TransactionImple.enlistResource - XAResource.start returned: XAException.XAER_PROTO for < 131075, 29, 27, 1--6edb9bdf:1214:4b5f53d2:501-6edb9bdf:1214:4b5f53d2:50a...

2010-01-26 15:00:03,719 ERROR [R.dennis] [STDERR] org.jboss.resource.connectionmanager.JBossLocalXAException: Trying to start a new tx when old is not complete! old: < 131075, 29, 27, 1--6edb9bdf:1214:4b5f53d2:489-6edb9bdf:1214:4b5f53d2:492...

from a call deep in the code the job calls, which I really don't want to have to try to modify.

I'm going to review transaction usage in the code used by the job. Any other suggestions? Thanks.

Sounds like something in your code (or the code it calls) either:

a) starts a new tx without first checking if one is already started, and working within that

or

b) forgets to commit

It could be that the code in your job is invoking a SessionBean or some service method setup with transaction interception that is demarcated "requires new transaction" -- but the job already has one in place.

I still don't have a complete solution that I understand, but I am successfully removing triggers, the original issue in this thread. I'll open a new thread if I can't figure out my other issues soon.

The solution we came to in order to remove triggers on successful job completion was to refactor code so that the StatefulJob implementation does nothing more than extract data from the merged job data map, and use that data to call an EJB method. The EJB retrieves the scheduler and cancels the trigger if his work completes successfully.

Quartz is now running _without_ a UserTransaction, and the database is being updated promptly.

What we found is that when the cancelTrigger(...) code is in the StatefulJob implementation, Quartz must have a UserTransaction or the trigger is not removed from the database for at least 5 minutes (as long as I was willing to wait and watch it) It just sits with QRTZ_TRIGGERS.TRIGGER_STATE=BLOCKED and QRTZ_FIRED_TRIGGERS.STATE=EXECUTING. But running Quartz with a UserTransaction caused "Could not enlist in transaction on entering meta-aware object!;" exceptions, regardless of whether the EJB was TransactionAttributeType.REQUIRED, SUPPORTS, or REQUIRES_NEW, even when the EJB did nothing other than log (to console) the fact that it was called.