Programación de primavera: @Scheduled vs Quartz

estoy leyendo el Primavera 3.0 documentos con respecto a la programación. Me inclino por JobDetailBean de Spring para Quartz. sin embargo, el @Programado la anotación ha captado mi atención. Parece que esta es otra forma de programar tareas utilizando Spring Framework. Según los documentos, Spring proporciona tres formas de programación:

1. @Programado
2. vía cuarzo
3. A través del temporizador JDK

No tengo ningún interés en el temporizador JDK. ¿Por qué debería elegir @Scheduled sobre Quartz? (Cuando menciono Cuarzo me refiero a usar el envoltorio de frijol de Spring para Cuarzo).

Digamos que mi caso de uso es lo suficientemente complejo como para comunicarme con un servicio web de terceros para importar y exportar datos en intervalos específicos.

Quartz es un orden de magnitud más complejo que el programador integrado de Spring, que incluye soporte para trabajos persistentes, transaccionales y distribuidos. Sin embargo, es un poco complicado, incluso con el soporte API de Spring.

Si todo lo que necesita es ejecutar métodos en un bean cada X segundos, o en un cronograma cron, entonces @Scheduled (o las diversas opciones en Spring’s <task> esquema de configuración) es probablemente suficiente

Tengo que exponer mi propia experiencia con respecto al uso de @Scheduled versus Quartz como implementación de programación en una aplicación Spring.

La programación de trabajos tenía los siguientes requisitos:

• Los usuarios finales deben tener la capacidad de guardar y programar (definir el tiempo de ejecución) sus propias tareas
• Los trabajos programados durante el tiempo de inactividad del servidor no deben omitirse de la cola de trabajos

Por lo tanto, tenemos que probar y usar la implementación de Quartz (versión 2.2.3) para admitir la persistencia de trabajos en una base de datos. Algunas conclusiones básicas son las siguientes:

• La integración con una aplicación Spring 4 MVC no es nada difícil usando el archivo quartz.properties.
• Tuvimos la posibilidad de elegir una segunda base de datos para almacenar los trabajos de la base de datos principal.
• Los trabajos programados durante el tiempo de inactividad del servidor comienzan a ejecutarse siempre que el servidor se active.
• Como beneficio adicional, logramos mantener en la base de datos principal información útil (y más orientada al usuario) sobre trabajos programados definidos por el usuario utilizando JobListener y TriggerListener.
• Quartz es una biblioteca muy útil en aplicaciones con requisitos de programación más complejos.

De acuerdo a Documentación de cuarzo

Podemos usar alguna característica más compleja que no existe en @Scheduler. por ejemplo:

1. en Quartz podemos poner un planificador en modo stand-by con
   scheduler.standby(); y volver a programarlo con scheduler.start();.
2. cerrar un programador antes de la ejecución del trabajo o después de eso con
   scheduler.shutdown(true); y scheduler.shutdown(false);
3. almacenar un trabajo para su uso posterior y cuando necesite el trabajo puede activarlo.

JobDetail job1 =newJob(MyJobClass.class).
withIdentity("job1","group1").
storeDurably().
build();

4. Agregue el nuevo trabajo al programador, indicándole que “reemplace” el trabajo existente con el nombre y el grupo proporcionados (si corresponde).

JobDetail job1 = newJob(MyJobClass.class).
withIdentity("job1", "group1").
build();

En Spring, puede programar tareas usando FixedRate, FixedDelay y cron. Pero la mayor parte del trabajo programado requiere un manejo dinámico del tiempo de ejecución. Entonces, en este escenario, es mejor usar Quartz, ya que brinda la opción de almacenar trabajos programados en DBJobstore y RAMJobstore.