In some companies, App Defender/AppLocker makes the entire Windows OS practically unusable. EXEs are blocked, and the virus scan slows any build to a crawl. Nevertheless, we still need to work, and WSL is often the only feasible solution. But how can we start, for example, Eclipse or any other application in WSL that requires a screen?

Solution

We might wither build on x11 (steps 4 and 5) or use the build in WSLg which should run out of the box:

1. Install eclipse or STS in Linux
2. Export the DISPLAY env variable export DISPLAY=:0
3. Run eclipse or any other application in Linux
4. (optional) Install x11 in Linux sudo apt install x11-xserver-utils
5. (optional) Install VcXsrv on windows

Install eclipse or Spring STS in Linux

We might either install eclipse with sudo apt install eclipse or as many other of us choose to install a different IDE here an example for spring sts (update the URL as needed to the current version):

wget https://cdn.spring.io/spring-tools/release/STS4/4.25.0.RELEASE/dist/e4.33/spring-tool-suite-4-4.25.0.RELEASE-e4.33.0-linux.gtk.x86_64.tar.gz
tar -xvf spring-tool-suite-4-4.25.0.RELEASE-e4.33.0-linux.gtk.x86_64.tar.gz
rm -rf spring-tool*
ln -s sts-4.25.0.RELEASE/SpringToolSuite4 sts

Export the DISPLAY env variable

In order to find our windows screen we have to define the DISPLAY destination with the same named environment variable. The simplest way is to extend the .profile that it is automatically exported on each shell start (or .zprofile if zsh is used).

export DISPLAY=:0

Run eclipse or any other application

Now we can either start eclipse using ./eclipse or the spring STS using ./sts.

In case of any issues the x11 app might help you e.g. using xeyes:

sudo apt install x11-apps
xeyes

Install x11 in Linux

x11 tools on Linux are responsible to send the screen information from our Linux system to windows and on the other hand receive mouse and keyboard commands. In ubuntu the tools can be installed by using:

sudo apt install x11-xserver-utils

This step is not need anymore on a newer WSL as by default windows support UI apps in the WSL using WSLg.

If x11 is used the DISPLAY variable has to be adjusted to point to the Windows Host machine.

Install VcXsrv on windows

In order to receive the screen information from Linux in Windows and to display the application started in Linux we need an x11 client here too. First we have to install VcXsrv and start it using XLaunch which will prompt us of the settings:

1. Multiple windows in the display settings, which allows us to start more than one app
2. Start no client which of course requires us to start the app in Linux manually later on

Everything else may stay in the default settings.

This step is not need anymore on a newer WSL as by default windows support UI apps in the WSL using WSLg.

Alternatives

• https://github.com/microsoft/wslg

In diesem Tutorial starten wir mit den Grundlagen der Datenbanktransaktionen in deiner Anwendung: – Transaktionen starten:

• Transaktion starten: Verstehe, wie Du Transaktionen in Spring Boot richtig initialisierst.
• Rollback-Strategien: Erlerne die wichtigsten Methoden, um Transaktionen bei Fehlern sicher zurückzusetzen.
• Annotations: Setze Annotations gezielt ein, um Transaktionen zu steuern.
• Programmatische Transaktionen: Implementiere Transaktionen programmatisch und gewinne maximale Kontrolle.
• Read Only: Transaktionen für GET Operationen
• Timeouts: Wie stelle ich bei einer Transaktion einen Timeout ein, was muss ich beachten?

Dieses Video ist perfekt für Entwickler, die ihre Fähigkeiten in Spring Framework erweitern und transaktionssichere Anwendungen erstellen möchten.

• Git Commit
• Git Projekt

Ereignisgesteuerte (Event Driven) Architekturen dienen keinem Selbstzweck. Häufig soll sie Problemen vorbeugen und uns helfen eine stabile Service Architektur zu entwickeln. Abseits vom „Happy Case“, was kann den wie und wo schief gehen; wie kann uns diese Architektur helfen?

Wir schauen uns drei typische Lösungsmethoden an:

1. Event Bus
2. Command Bus
3. Data Bus

• Transaktionen
• ACID
• Isolationslevel
• Locks

• Setup Quartz in JEE
• Setup Quartz in Spring
• Source Code to this page

Trigger and Job names

During the configuration we may select for each job and each trigger a name and a group. The last values gives us a way to cluster. The first one is in interesting.

Job names

Setting manually a job names makes the code refactoring save. By default the spring quartz integration uses the bean name. Which is good for the start, but in case that we refactor the code and rename the bean we have to keep in mind to delete the old job in the quartz tables. As so it is usually saver to define a name, which we keep stable:

@Bean
    public JobDetailFactoryBean retryJob() {
        final var jobDetailFactory = new JobDetailFactoryBean();
        jobDetailFactory.setJobClass(RetryJob.class);
        // static name, we may of course also define a constant
        jobDetailFactory.setName("RETRY-JOB");
        jobDetailFactory.setDurability(true);
        return jobDetailFactory;
    }

If we now change the class name or packe structure it will get updated as soon we deploy the new version instead added to the job list.

Trigger names

The combination of a trigger name and trigger group has to be unique. Which gives us a very simple way to verify if a particular job was already scheduled or not. E.g. if we want to schedule a timer to notify a user that he has to change his password in 30 days we could just:

  public TriggerKey notifyUser(String user) throws SchedulerException {
        TriggerKey key = new TriggerKey(user, NotifyUserJob.ID);
        var t = TriggerBuilder.newTrigger()
                .forJob(JobKey.jobKey(NotifyUserJob.ID))
                .startAt(Date.from(Instant.now().plusMillis(1_000 * 60 * 60 * 24 * 30)))
                .usingJobData("user", user)
                .withIdentity(key)
                .build();
        scheduler.scheduleJob(t);
        return t.getKey();
    }

Now we get a ObjectAlreadyExistsException if we trigger it again and we can easily delete the trigger if the user changes the password before it would trigger. We may also update it.

Retry Triggers

A very common case is not only too trigger a task but also have a way to implement a kind of retry. With quartz this is pretty straight forward. In general we have to possibilities:

1. Trigger immediately
2. Queue a new Trigger to run the same job with a delay

Trigger immediately

In the most simple way we can just catch any exception and re-trigger the job again. Any change to the JobData will be stored in an own transaction into the quartz tables. Which gives us a simple way to store intermediate results or just a retry counter; separately of our main application transaction and DB changes, which can rollback in peace.

public class RetryJob extends QuartzJobBean {

    @Autowired private YourService yourService;
    
    @Override
    protected void executeInternal(JobExecutionContext context) throws JobExecutionException {
        Integer retryCount = (Integer)context.getMergedJobDataMap().getOrDefault("retryCount", 1);
        try {
            yourService.doStuff();
        } catch (Exception e) {
            if (retryCount >= 3) {
                throw e;
            } else {
                // don't use the getMergedJobDataMap of spring, it will not be updated
                context.getTrigger().getJobDataMap().put("retryCount", retryCount + 1);
                throw new JobExecutionException("yourService.doStuff failed  " 
                        + retryCount + " times. Will retry. " + e.getMessage(), 
                        true);
            }
        }
    }
}

Trigger later

Usually we want to wait a bit before we retry, which is just updating the trigger:

    @Override
    protected void executeInternal(JobExecutionContext context) throws JobExecutionException {
        Integer retryCount = (Integer)context.getMergedJobDataMap().getOrDefault("retryCount", 1);
        try {
            yourService.doStuff();
        } catch (Exception e) {
            if (retryCount > 3) {
                throw e;
            } else {
                // we have to use the trgger data, as we repalce the trigger now
                context.getTrigger().getJobDataMap().put("retryCount", retryCount + 1);
                
                final var tb = context.getTrigger().getTriggerBuilder();
                tb.startAt(Date.from(Instant.now().plusSeconds(retryCount * 10)));
                scheduler.rescheduleJob(context.getTrigger().getKey(), tb.build());
            }
        }
    }

Example on Git.

Delete all job triggers

If we want to cancel all triggers for a job we can just list and delete them:

List<? extends Trigger> triggers = scheduler.getTriggersOfJob(xyzJob.getKey());
scheduler.unscheduleJobs(triggers.stream().map(t -> t.getKey()).toList());

Spring comes already with an own timer and this is fine if we have very simple requirements and we don’t really care about state or on which pod the timer is actually running. To be more precise the timer/ job is running in each of our spring containers independently.

Lets be honest, this is usually never really the case and so it is common to invite ShedLock to the party. Are we done then?

Usually no, honestly we want in the most cases just a bit more:

• Run jobs in the cluster on different nodes simultaneous
• Have a kind of state management
• The ability to provide some kind of configuration to each run
• Have some kind of way for easy retries etc.

Hey why don’t use Spring Batch then?

Because to have just a timer and not really a batch-job it is somehow the wrong tool. Furthermore Spring-Batch is build with a different goal in mind, where we start a container with one job inside to process mass of data. Quartz is more a timer, which we want to use to trigger either smaller task in our application or run kind of repeating small task and are more concerned to orchestrate and Monitor them.

• Spring Batch = Batch Framework to handle large datasets which should be processed, usually in an own container / pod for the duration of the Job
• Quartz = Timer which also supports a JDBC/ REDIS store for smaller timer jobs which should run in our app cluster

Steps for the integration

• Setup the DB
• Configure Quartz Scheduler
• Configure CDI Job Factory
• Register our timers
• Set a thread priority for our job

Setup the DB

Overall quartz comes with SQL scripts and liquibase scripts you may just include. Read here. For unit test we can just simply use the build in feature:

spring:
  quartz:
    jdbc:
      initialize-schema: always

Configure Quartz Scheduler

We will use the CMT Store here, for more details because of the why please read the following tutorial.

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

After adding the dependency we have to configure Quartz, in this example we set the thread count to 2, adjust this value based on your needs. The following configuration will usually create a LocalDataSourceJobStore which is an JobStoreCMT.

spring:
  quartz:
    wait-for-jobs-to-complete-on-shutdown: false
    job-store-type: jdbc
    overwrite-existing-jobs: true
    jdbc:
      initialize-schema: always
    properties:
      org.quartz.jobStore.isClustered: true
      org.quartz.scheduler.instanceId: AUTO
      org.quartz.scheduler.skipUpdateCheck: true
      org.quartz.threadPool.threadCount: 2
  
  datasource:
    url: jdbc:h2:file:./quartz-db
    username: sa
    password: 

Yes thats basically it, we will discuss details in further deep dives, but for now lets gets a job running.

Create a timer Job

To setup a timer we have to:

1. Add a job class
2. Configure the timer

Add a Spring configuration

// runs only one of these jobs in out cluster
// note we have no spring annotation here, but it contains spring beans
@DisallowConcurrentExecution 
public class QuatzTimerJob implements Job {
	// we can use spring beans, yes we cam
    @Autowired YourService yourService;
    @Override
    public void execute(JobExecutionContext context) throws JobExecutionException {
		yourService.doSomething();
    }

}

Configure the timer

@Configuration
public class QuartzTimerConfiguration {
	// this registers our job itself
    @Bean
    public JobDetailFactoryBean quatzTimerJob() {
        final var jobDetailFactory = new JobDetailFactoryBean();
        jobDetailFactory.setJobClass(QuatzTimerJob.class);
        jobDetailFactory.setDescription("Simple timer like @Scheduled - but already like with ShedLock");
        jobDetailFactory.setDurability(true);
        return jobDetailFactory;
    }
    // here we add the timer, in this case every 30s, with a lower priority as normal for the job
    @Bean
    public SimpleTriggerFactoryBean trigger(JobDetail quatzTimerJob) {
        final var trigger = new SimpleTriggerFactoryBean();
        trigger.setJobDetail(quatzTimerJob);
        trigger.setRepeatInterval(30_000);
        trigger.setPriority(Thread.NORM_PRIORITY - 1);
        trigger.setRepeatCount(SimpleTrigger.REPEAT_INDEFINITELY);
        return trigger;
    }
}

Trigger a job

In difference to a normal Spring timer we may now fire triggers for Quartz Jobs, even add data to the triggers itself, at let Quartz handle the heavy work for us. Handy if we want QUEUE some work, or just distribute the load in our cluster to all available nodes. For this we have to:

1. Create a job instance we want to execute
2. Configure the job – but now without any default trigger
3. Create somewhere in our code the triggers, usually with some payload data

Create a job

Very simple thing here, just getting one value from the job context and calling out service.

public class TriggeredJob implements Job {

    @Autowired YourService yourService;
    @Override
    public void execute(JobExecutionContext context) throws JobExecutionException {
        long count = context.getMergedJobDataMap().getLong("count"));
        yourService.doSomething(count);
    }

}

Configure the job

The only special thing here is that we request a recovery on a different node, should this node for some reason die during the execution of the job.

@Configuration
public class QuartzJobConfiguration {
    @Bean
    public JobDetailFactoryBean createStoreItemsJob() {
        final var jobDetailFactory = new JobDetailFactoryBean();
        jobDetailFactory.setJobClass(CreateStoreItemsJob.class);
        jobDetailFactory.setDescription("Job we directly trigger if we want to run it");
        jobDetailFactory.setDurability(true);
        jobDetailFactory.setRequestsRecovery(true);
        return jobDetailFactory;
    }
}

Trigger the job

    @Autowired Scheduler scheduler;
    @Autowired JobDetail createStoreItemsJob;

    @Transactional
    public void triggerStoreItemCreation() throws SchedulerException {
        Trigger t = TriggerBuilder.newTrigger()
            .forJob(createStoreItemsJob)
            .startNow() // run on this node if possible, means we have threads
            .usingJobData("count", count)
            .build();
        
        scheduler.scheduleJob(t);
    }

Testing it

You may wonder why we used a file DB in this configuration. Only with a DB which contains the trigger data after a restart you may play around and also kill the running Spring application. After a restart the jobs are triggered again.

Alternatives

We could also go for a command queue using e.g. JMS. This aproach would require additional infrastructure in form of a persistent broker. Which could be easy in the cloud but rather difficult if you have to operate and maintain it on your own. In the end a data store which have to join our DB transactions in case ACID is an issue and it always is.

Links

• https://github.com/sterlp/training/tree/master/spring-quartz
• https://spring.getdocs.org/en-US/spring-boot-docs/boot-features/boot-features-quartz.html
• http://www.quartz-scheduler.org/documentation/quartz-2.3.0/cookbook/