Métodos de gestión de tareas mediante un planificador
El planificador proporciona varios métodos de gestión de tareas.
- suspend()
- Suspende una tarea. La tarea no se ejecuta hasta que se reanude.
- resume()
- Reanuda una tarea suspendida previamente.
- cancel()
- Cancela una tarea. La tarea no se ejecuta y no se puede continuar.
- purge()
- Suprime de forma permanente una tarea cancelada del almacén persistente.
- getStatus()
- Devuelve el estado actual de la tarea.
//Cree la tarea.
TaskInfo taskInfo = ...
TaskStatus status = scheduler.create(taskInfo);
//Obtener el identificador de la tarea
String taskId = status.getTaskId();
//Cancelar la tarea. Especificar el distintivo purgeAlso para que la tarea no permanezca en el almacén persistente
scheduler.cancel(taskId,true);
set jndiName sched/MyScheduler
# Correlacione el nombre JNDI con el nombre mbean. El nombre mbean se
# se forma sustituyendo la barra / del nombre jndi por un . y añadiendo el
# prefijo Scheduler_
regsub -all {/} $jndiName "." jndiName
set mbeanName Scheduler_$jndiName
puts "Búsqueda del MBean del planificador $mbeanName"
set sched [$AdminControl queryNames WebSphere:*,type=WASScheduler,name=$mbeanName]
puts $sched
# Obtenga el formato ObjectName del MBean del planificador
set schedO [$AdminControl makeObjectName $sched]
# Cree un objeto TaskInfo
# (se ha excluido parte del código)
set params [java::new {java.lang.Object[]} 1]
$params set 0 $taskInfo
set sigs [java::new {java.lang.String[]} 1]
$sigs set 0 com.ibm.websphere.scheduler.TaskInfo
set taskStatus [java::cast com.ibm.websphere.scheduler.TaskStatus [$AdminControl invoke_jmx $schedO
create $params $sigs]]
set taskID [$taskStatus getTaskId]
puts "Task Created. TaskID= $taskID"
# Cancele la tarea mediante el ID de tarea del objeto TaskStatus devuelto durante la creación.
set params [java::new {java.lang.Object[]} 1]
$params set 0 false
set sigs [java::new {java.lang.String[]} 1]
$sigs set 0 java.lang.boolean
set taskStatus [java::cast com.ibm.websphere.scheduler.TaskStatus [$AdminControl invoke_jmx $schedO
cancel $params $sigs]]
Transaccionalidad. Todos los métodos de la API del planificador son transaccionales. Si existe un contexto transaccional global, se utiliza para realizar la operación. Si se emite una excepción inesperada, se marcará la transacción para retrotraerla y el emisor deberá manejarla adecuadamente. Si se emite una excepción esperada o declarada, la transacción permanece intacta y el proceso que efectúa la llamada tiene que determinar si retrotrae o compromete la transacción. Si se retrotrae la transacción en ese punto, todas las operaciones del planificador efectuadas en la transacción también se retrotraerán.
Si existe un contexto transaccional local, se suspende y comienza un contexto transaccional global nuevo. Asimismo, si no hay activo un contexto transaccional, comenzará un contexto transaccional global. En los dos casos, si se emite una excepción inesperada, se retrotraerá la transacción. Si se emite una excepción inesperada, se confirmará la transacción.
Si otra hebra está modificando la tarea en cuestión de forma concurrente, se lanza una excepción TaskPending. Esto se debe a que los planificadores bloquean la base de datos de forma optimista. A continuación, la aplicación que efectúa la llamada puede volver a intentar la operación.
Las funciones de gestión de tareas se pueden bloquear si la tarea se está ejecutando en ese momento. Como el planificador garantiza que cada tarea se ejecute una sola vez, se debe bloquear la tarea durante el tiempo que dure la ejecución de una tarea. Del mismo modo, si se modifica una tarea utilizando una de las funciones de gestión pero no se compromete la transacción global, se bloqueará cualquier otra función de gestión emitida desde otra transacción para esa tarea.
El método TaskHandler.process() de una tarea de beans de sesión sin estado puede modificar su propio estado. No obstante, la tarea debe estar ejecutándose en la misma transacción que el planificador. Por lo tanto, una tarea en ejecución sólo puede modificarse si utiliza los tipos de transacción gestionados por contenedor Required (Necesario) o Mandatory (Obligatorio). Si el tipo de transacción Requires New (Requiere nueva) se especifica en el método process()method, todas las funciones de gestión entrarán en punto muerto.
Todos los métodos definidos por la API del planificador se describen en la documentación de la API.