惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Microsoft Security Blog
Microsoft Security Blog
J
Java Code Geeks
GbyAI
GbyAI
aimingoo的专栏
aimingoo的专栏
L
LangChain Blog
I
InfoQ
D
Docker
F
Fortinet All Blogs
Y
Y Combinator Blog
Martin Fowler
Martin Fowler
月光博客
月光博客
B
Blog
Engineering at Meta
Engineering at Meta
T
Tailwind CSS Blog
罗磊的独立博客
博客园_首页
G
Google Developers Blog
Stack Overflow Blog
Stack Overflow Blog
Recent Announcements
Recent Announcements
D
DataBreaches.Net
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
B
Blog RSS Feed
IT之家
IT之家
V
V2EX

Maciej Walkowiak - Java & Spring

Blog Generating HTTP clients in Spring Boot application from OpenAPI spec PostgreSQL and UUID as primary key Dynamic Projections with Spring Data JPA Container logs with Spring Boot and Testcontainers Reified Generics in Java? Faster integration tests with reusable Testcontainers and Flyway The best way to use Testcontainers with Spring Boot Spring Boot & Flyway - clear database between integration tests What's new in Spring? Activate Maven Profile by Operating System Spring Boot with Thymeleaf and Tailwind CSS - Complete Guide How to publish a Java library to Maven Central - Complete Guide Docker Compose - waiting until containers are ready Single file Java applications with JBang Beautiful bash scripts with Gum Running Java on CRaC How to log PostgreSQL queries with Testcontainers Spring Boot 3.0 & GraalVM Native Image - not a free lunch Creating Spring Cloud Function projects with AWS SAM Loading classpath resources to String with a custom JUnit extension Creating Project Templates with Cookiecutter Auto-Registering JUnit 5 extensions Spring Boot component scanning without annotations Listing Maven dependencies in Spring Boot Actuator Info endpoint Spring Cloud AWS 2.3 RC2 Released How I built vlad-cli - command line interface to Vlad Mihalcea The State of Java Relational Persistence On Choosing a Tech Stack
Running one-time jobs with Quartz and Spring Boot
2023-04-27 · via Maciej Walkowiak - Java & Spring
Published on
  • Spring Boot
  • Quartz
  • Scheduled

Scheduling jobs with Quartz has been discussed numerous times. However, it is worth to know that Quartz can be used not just to run jobs every X hours or based on a CRON expression, but also to execute specific code once at a specified time in the future.

I believe that in some specific use cases, following this approach can dramatically simplify your architecture and implementation. Let's see step by step how to do it.


Setup Quartz ​

Spring Boot comes with first-class support for Quartz: a starter and auto-configuration, so most of the things work out of the box.

First lets add the dependency to spring-boot-starter-quartz:

xml

<dependency>
	<groupId>org.springframework.boot</groupId>
	<artifactId>spring-boot-starter-quartz</artifactId>
</dependency>

Define a Job ​

Let's say you want to send a follow-up email to a user 24 hours after they register, asking about their experience so far. To make it happen, you'll need to implement a class that implements org.quartz.Job and turn it into a Spring bean:

java

import org.quartz.Job;
import org.quartz.JobExecutionContext;
import org.quartz.JobExecutionException;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import org.springframework.stereotype.Component;

@Component
public class EmailJob implements Job {
    private static final Logger LOGGER = LoggerFactory.getLogger(EmailJob.class);

    @Override
    public void execute(JobExecutionContext jobExecutionContext) throws JobExecutionException {
        String userId = jobExecutionContext.getJobDetail().getJobDataMap().getString("userId");
        // ...
    }
}

To schedule the job, you'll need to create an instance of org.quartz.JobDetail, which points to the Job that needs to run and can have an execution-specific bag of data called job data. Then create a trigger that defines when the Job with a context defined in JobDetail should run. Finally, call org.quartz.Scheduler#scheduleJob with the JobDetail and Trigger.

java

import java.util.UUID;

import org.quartz.DateBuilder;
import org.quartz.JobDetail;
import org.quartz.Scheduler;
import org.quartz.SchedulerException;
import org.quartz.Trigger;

import org.springframework.stereotype.Service;

import static org.quartz.DateBuilder.futureDate;
import static org.quartz.JobBuilder.newJob;
import static org.quartz.TriggerBuilder.newTrigger;

@Service
public class RegistrationService {
    private final Scheduler scheduler;

    public RegistrationService(Scheduler scheduler) {
        this.scheduler = scheduler;
    }

    void registerUser(User user) throws SchedulerException {
        // save user
        // ...
        // schedule email
        JobDetail job = newJob(EmailJob.class)
                .withIdentity("email-job-" + user.id())
                .usingJobData("userId", user.id())
                .build();
        Trigger trigger = newTrigger()
                .withIdentity("trigger-email-job-" + user.id())
                .startAt(futureDate(24, DateBuilder.IntervalUnit.HOUR))
                .build();

        scheduler.scheduleJob(job, trigger);
    }
}

To quickly summarize above code: when registerUser method is called, Quartz schedules to run an EmailJob with a userId in the job data, exactly in 24 hours from now.

JobDetails#identity and Trigger#identiy must be unique. You can't schedule two jobs with the same identity.

WARNING

By default, jobs are stored in memory, which means that if the application is restarted, all scheduled jobs are lost - not cool for production.

Persisting Jobs in a database ​

Thankfully, Quartz supports JDBC store, which stores jobs in a relational database. To activate it, you need to configure Quartz in Spring Boot's application.properties.

properties

spring.quartz.job-store-type=jdbc
spring.quartz.jdbc.initialize-schema=always

On application startup, Quartz creates all the tables it needs, but when you try to schedule a job, you might get an exception:

org.quartz.JobPersistenceException: Couldn't acquire next trigger: Couldn't retrieve trigger: Bad value for type long : \x
       at org.quartz.impl.jdbcjobstore.JobStoreSupport.acquireNextTrigger(JobStoreSupport.java:2923) ~[quartz-2.3.2.jar:na]
       at org.quartz.impl.jdbcjobstore.JobStoreSupport$41.execute(JobStoreSupport.java:2805) ~[quartz-2.3.2.jar:na]
       at org.quartz.impl.jdbcjobstore.JobStoreSupport$41.execute(JobStoreSupport.java:2803) ~[quartz-2.3.2.jar:na]
       at org.quartz.impl.jdbcjobstore.JobStoreSupport.executeInNonManagedTXLock(JobStoreSupport.java:3864) ~[quartz-2.3.2.jar:na]
       at org.quartz.impl.jdbcjobstore.JobStoreSupport.acquireNextTriggers(JobStoreSupport.java:2802) ~[quartz-2.3.2.jar:na]
       at org.quartz.core.QuartzSchedulerThread.run(QuartzSchedulerThread.java:287) ~[quartz-2.3.2.jar:na]
Caused by: org.quartz.JobPersistenceException: Couldn't retrieve trigger: Bad value for type long : \x
       at org.quartz.impl.jdbcjobstore.JobStoreSupport.retrieveTrigger(JobStoreSupport.java:1538) ~[quartz-2.3.2.jar:na]
       at org.quartz.impl.jdbcjobstore.JobStoreSupport.acquireNextTrigger(JobStoreSupport.java:2854) ~[quartz-2.3.2.jar:na]
       ... 5 common frames omitted
Caused by: org.postgresql.util.PSQLException: Bad value for type long : \x
       at org.postgresql.jdbc.PgResultSet.toLong(PgResultSet.java:3233) ~[postgresql-42.5.4.jar:42.5.4]
       at org.postgresql.jdbc.PgResultSet.getLong(PgResultSet.java:2449) ~[postgresql-42.5.4.jar:42.5.4]
       at org.postgresql.jdbc.PgResultSet.getBlob(PgResultSet.java:455) ~[postgresql-42.5.4.jar:42.5.4]
       at org.postgresql.jdbc.PgResultSet.getBlob(PgResultSet.java:441) ~[postgresql-42.5.4.jar:42.5.4]
       at com.zaxxer.hikari.pool.HikariProxyResultSet.getBlob(HikariProxyResultSet.java) ~[HikariCP-5.0.1.jar:na]
       at org.quartz.impl.jdbcjobstore.StdJDBCDelegate.getObjectFromBlob(StdJDBCDelegate.java:3190) ~[quartz-2.3.2.jar:na]
       at org.quartz.impl.jdbcjobstore.StdJDBCDelegate.selectTrigger(StdJDBCDelegate.java:1780) ~[quartz-2.3.2.jar:na]
       at org.quartz.impl.jdbcjobstore.JobStoreSupport.retrieveTrigger(JobStoreSupport.java:1536) ~[quartz-2.3.2.jar:na]
       ... 6 common frames omitted

To fix it, you must set a Quartz property org.quartz.jobStore.driverDelegateClass with the value specific to the database type you use. For PostgreSQL it is org.quartz.impl.jdbcjobstore.PostgreSQLDelegate.

properties

spring.quartz.properties.org.quartz.jobStore.driverDelegateClass=org.quartz.impl.jdbcjobstore.PostgreSQLDelegate

Quartz creates following database tables:

  • qrtz_blob_triggers
  • qrtz_calendars
  • qrtz_cron_triggers
  • qrtz_fired_triggers
  • qrtz_job_details
  • qrtz_locks
  • qrtz_paused_trigger_grps
  • qrtz_scheduler_state
  • qrtz_simple_triggers
  • qrtz_simprop_triggers
  • qrtz_triggers

Once the job is scheduled, a row is added to qrtz_simple_triggers and qrtz_job_details. When the job execution is over, entries get deleted. But, that means we lose track of jobs that have already run. To avoid this, make JobDetails durable with storeDurably():

java

JobDetail job = newJob(EmailJob.class)
    .withIdentity("email-job-" + user.id())
    .usingJobData("userId", UUID.randomUUID().toString())
    .storeDurably()
    .build();

One last thing: by default, Job data set on JobDetails is serialized to bytes using Java serialization. Sure, you can pass any serializable object, but you'll have to deal with potential issues with Java serialization. So, instead, configure Quartz to save job data as a simple properties map and only pass strings, numbers, or booleans:

properties

spring.quartz.properties.org.quartz.jobStore.useProperties=true

Quartz tables database schema ​

As previously discussed, Quartz offers a convenient feature that automates the creation of database tables through the adjustment of the spring.quartz.jdbc.initialize-schema setting to always. However, this approach can result in a lack of control over the database schema implemented by the application, potentially leading to hard to predict behavior when upgrading to a new Quartz version that changes the schema.

To mitigate this issue, a superior approach involves modifying the setting to never and creating a Flyway/Liquibase migration file by copying the database-specific SQL file from Quartz's sources: https://github.com/quartz-scheduler/quartz/tree/main/quartz/src/main/resources/org/quartz/impl/jdbcjobstore

Conclusion ​

Hope this was clear and you find it useful. Feel free to drop a comment if you found any mistake or have a question. Also, feel free to reach out to me on twitter.com/maciejwalkowiak.

Let's stay in touch and follow me on Twitter: @maciejwalkowiak

Subscribe to RSS feed