Java – Pauls Blog

A Bounded, Thread-Safe In-Memory Store for Java

Paul Sterl — Tue, 30 Dec 2025 14:55:43 +0000

Problem

In test scenarios or lightweight application components, there is a need for a simple, thread-safe, in-memory data store that can temporarily hold a limited number of objects. The store should be easy to use, avoid external dependencies (e.g., databases), support generation and use of unique identifiers as keys, and automatically evict the oldest entries when a predefined capacity is exceeded. This enables predictable memory usage while providing fast access to recently stored data.

Solution

import java.util.LinkedHashMap;
import java.util.Map;
import java.util.UUID;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;

public class MemoryStore {

    private final Lock lock = new ReentrantLock();
    private final int maxElements;

    private final Map data = new LinkedHashMap<>() {
        // called during put and ensures the map doesn't grow
        @Override
        protected boolean removeEldestEntry(Map.Entry eldest) {
            return size() > maxElements;
        }
    };

    public MemoryStore(int maxElements) {
        if (maxElements < 1) {
            throw new IllegalArgumentException("maxElements must be > 1");
        }
        this.maxElements = maxElements;
    }
    
    public void store(T value) {
        this.store(UUID.randomUUID().toString(), value);
    }

    public void store(String key, T value) {
        lock.lock();
        try {
            data.put(key, value);
        } finally {
            lock.unlock();
        }
    }

    public T get(String key) {
        lock.lock();
        try {
            return data.get(key);
        } finally {
            lock.unlock();
        }
    }
    
    public int size() {
        lock.lock();
        try {
            return data.size();
        } finally {
            lock.unlock();
        }
    }
    
    public LinkedHashMap data() {
        lock.lock();
        try {
            return new LinkedHashMap<>(this.data);
        } finally {
            lock.unlock();
        }
    }
}

Spring Persistent Tasks

Paul Sterl — Sun, 20 Apr 2025 07:16:43 +0000

A simple task management framework designed to queue and execute asynchronous tasks with support for database persistence and a user-friendly interface. It can be used to implement scheduling patterns or outbound patterns.

Focus is the usage with spring boot and JPA.

https://github.com/sterlp/spring-persistent-tasks

Key Features

JPA-Powered Persistence – Automatically persists tasks to your database
Spring Boot Auto-Configuration – Simple setup with @EnableSpringPersistentTasks
Clustering Support – Built-in lock management for distributed environments
Type-Safe Tasks – Generic task definitions with state objects
Retry Mechanisms – Automatic retry policies for failed executions
Transactional Integration – Works with Spring’s transaction management
Queue Management – Intelligent task queuing and prioritization
Different DB Supports
- MsSQL
- MariaDB
- Postgres

React & Spring Boot

Paul Sterl — Wed, 11 Dec 2024 18:36:41 +0000

Problem

We want to combine Spring Boot with a simple React frontend. Use the React development features but also be able to use the Spring IDE. In the end, everything should be built using Maven and nicely packed into a JAR, just like any other Microservice. Let’s get started.

Multi-Module project

First we create a spring project here backend folder and a react project in the frontend folder. The root pom should help us to build both projects in one run:

Root pom.xml


    4.0.0

    org.foo.bar
    project-root
    0.1.0-SNAPSHOT
    pom

    
        21
        ${java.version}
        ${java.version}
        UTF-8
        UTF-8
    

    
        frontend
        backend
    

  	
    
        
            
                org.springframework.boot
                spring-boot-dependencies
                3.3.6
                pom
                import

Backend pom.xml

This is straight forward the generated pom from spring with just the dependency to the frontend project.



    4.0.0
    
        org.foo.bar
        project-root
        0.1.0-SNAPSHOT
        ../pom.xml
    

    project-backend

    
      	
        
            org.foo.bar
            project-frontend
            ${project.version}
        
      	
      
        
            org.springframework.boot
            spring-boot-starter-web
          
        
            org.projectlombok
            lombok
            true
        
        
            org.springframework.boot
            spring-boot-starter-test
            test
        
    
    
        
            
                org.springframework.boot
                spring-boot-maven-plugin

Frontend pom.xml

Now we have todo more stuff:

Ensure the dist result is added to the JAR
Generate during the generate-resources phase also the content for the dist folder
Ensure that during a mvn clean all gets deleted



    4.0.0
    
        org.foo.bar
        project-root
        0.1.0-SNAPSHOT
        ../pom.xml
    

    project-frontend
    
    
        
            org.springframework.boot
            spring-boot-starter-web
            provided
        
    
    
    
        
        
            
                dist
            
        

        
          	
            
                org.codehaus.mojo
                exec-maven-plugin
                3.5.0
                
                    
                        npm install
                        
                            exec
                        
                        generate-resources
                        
                            npm
                            
                                install
                                --prefer-offline
                                --no-audit
                                --progress=false
                            
                        
                    

                    
                        npm build
                        
                            exec
                        
                        generate-resources
                        
                            npm
                            
                                run
                                build
                            
                        
                    
                
            
            
            
                org.apache.maven.plugins
                maven-clean-plugin
                3.4.0
                
                    
                        
                            node_modules
                        
                        
                            dist

Ensure the result in the dist folder is compatible to Spring

Spring will pick up automatically any static resources which are placed in the static folder. Here is an example for vite to do so in the vite.config.js:

export default defineConfig({
  plugins: [react()],
  build: {
    outDir: './dist/static',
    emptyOutDir: true, // also necessary
  }
})

Going beyond

Sometime it is useful to host the UI in a sub path lets say my-ui, so the url would be http://localhost:8080/my-ui

For that we have to adjust the vite.config.js:

export default defineConfig({
  plugins: [react()],
  base: 'my-ui',
  build: {
    outDir: './dist/static/my-ui',
    emptyOutDir: true,
  }
})

Now it would also be helpful if we don’t have to directly type the index.html but tell Spring always to re-route.

For that we have to add a Spring Configuration Class:

package org.foo.bar;

import org.springframework.context.annotation.Configuration;
import org.springframework.web.servlet.config.annotation.ViewControllerRegistry;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;

@Configuration
public class MyFrontedConfig implements WebMvcConfigurer {
    @Override
    public void addViewControllers(ViewControllerRegistry registry) {
        registry.addViewController("/my-ui").setViewName("/my-ui/index.html");
        registry.addRedirectViewController("/my-ui/", "/my-ui");
    }
}

Add cache control to static react assets

In the end int would also be nice that the generated static resources are cached by the client e.g. for a year. We will extend the MyFrontedConfig class with:

    @Override
    public void addResourceHandlers(ResourceHandlerRegistry registry) {
        registry.addResourceHandler("/my-ui/assets/**") 
                .addResourceLocations("classpath:/static/my-ui/assets/") 
                .setCacheControl(CacheControl.maxAge(365, TimeUnit.DAYS));
    }

Transaktionsmanagement mit Spring, JPA, Hibernate

Paul Sterl — Sat, 31 Aug 2024 15:02:17 +0000

Lerne die Grundlagen des Transaktionsmanagements in modernen Datenbanken kennen, und erfahre, wie du mit Spring Boot, Spring Data, JPA und Hibernate effektiv arbeitest.

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.

Grundlagen Datenbanken | als Entwickler | Datenbank Locks vs Write Ahead | Spring | JPA | Hibernate

Paul Sterl — Sat, 13 Jan 2024 10:03:48 +0000

Last uns zusammen ein State Persistence Anwendung auf eine Write Ahead Anwendung abändern und die Verbesserung in der Skalierbarkeit dieser betrachten.

Wie synchronisieren wir parallelle Objektzugriffe in Java und Spring Boot, um die Skalierbarkeit unseres Systems zu optimieren?
Praktische Lösungen: Wie verarbeitet ein Java Spring Boot System viele Updates auf einmal nach einer Downtime?
Strategien für Lastspitzen in der Praxis: Einsatz von DB Locks in Java und Spring Boot.
Praktische Tipps und Tricks: Vor- und Nachteile von Locks in der Java Spring Boot Anwendung.
Weitere Optimierungsmöglichkeiten in der Java Spring Boot Architektur:
- Umsetzung von Write Ahead Log in Java und Spring Boo, welche Modifikationen sind notwendig?
- Was bring das an mehr Skalierbarkeit?

Microservices orchestrieren | Workflows | ESB | Event Bus

Paul Sterl — Tue, 03 Oct 2023 09:04:15 +0000

In einer Service- bzw. Microservice-Architektur stellt sich irgendwann unweigerlich die Frage wie man komplexe Workflows, die über mehrere Services hinweg gehen, orchestrieren möchte. Dabei stehen sich die Event- und die Workflow-Architektur anscheinend als unterschiedliche Paradigmen gegenüber. Wie können wir mit einfachen Architekturmaßnahmen die Arbeitsteilung von Teams/Abteilungen unterstützen?

Welche Architektur sollen wir wählen?
Ist es wirklich ein entweder oder?
Was wären die Vor- bzw. Nachteile?

Datenbank| Transaktionen | Isolationlevel | Locks | Hibernate | JPA | Spring Boot

Paul Sterl — Mon, 02 Oct 2023 11:40:50 +0000

Um weiterführende Konzepte besser nachvollziehen zu können, wollen wir uns in den Grundlagen Datenbanken mit Spring Boot, Isolation Level (Isolationsgrad) und Locks beschäftigen.

Quartz integration in Spring

Paul Sterl — Fri, 01 Jul 2022 19:50:50 +0000

Why Quartz? motivation

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.

		
			org.springframework.boot
			spring-boot-starter-quartz

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:

Note: We init the DB just with quartz itself. But quartz contains in the core a liquibase and a SQL file which you may include into your DB update process.

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:

Add a job class
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:

Create a job instance we want to execute
Configure the job – but now without any default trigger
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

Note: The usage of @Transactional, this is by purpose, to ensure the trigger gets removed if we happen to rollback the transaction. If it is missing, quartz will silently create an own one.

    @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.

JPA Model testing with Hibernate Statistics

Paul Sterl — Sun, 01 Aug 2021 11:25:00 +0000

Problem

Often we write JPA Entity classes an have to ensure in a larger team that refactoring doesn’t create performance problems or logical errors in the entity model usual problems are:

Missing fetch joins in Queries
- Which leads to slow fetch joins
Wrong direction of Entity relations
- which leads to updates after inserts
- or even to deletes and reinserts of data
Wrong transaction boundaries
- Which leads to multiple transactions for one logical business operation

@Component
public class HibernateAsserts {
  private final Statistics statistics;

  public HibernateAsserts(EntityManager entityManager) {
    try (Session session = entityManager.unwrap(org.hibernate.Session.class)) {
      @SuppressWarnings("resource")
      SessionFactory factory = session.getSessionFactory();
      factory.getStatistics().setStatisticsEnabled(true);
      statistics = factory.getStatistics();
    }
  }
  
  public HibernateAsserts assertTrxCount(int expected) {
    long value = statistics.getTransactionCount();
    if (value != expected) {
      logSummary();
      fail("Expected " + expected + " TransactionCount, but found " + value);
    }
    return this;
  }
  
  public HibernateAsserts assertInsertCount(int expected) {
    long value = statistics.getEntityInsertCount();
    if (value != expected) {
      logSummary();
      fail("Expected " + expected + " EntityInsertCount, but found " + value);
    }
    return this;
  }

  public void reset() {
    statistics.clear();
  }

  public void logSummary() {
    statistics.logSummary();
  }
}

In your test

@SpringBootTest
class MyTestClassTest {

  @Autowired private SubjectUnderTest subject;
  @Autowired private HibernateAsserts hibernateAsserts;
  
  @Test
  void textMyBusinessMethod() {
    // GIVEN
    // custom data setup for the test

    // WHEN
    hibernateAsserts.reset(); // ensure the setup is not in the stats
    subject.runBusinessMethod();
    
    // THEN
    // any business asserts
    hibernateAsserts
      .assertTrxCount(1)
      .assertInsertCount(1);
  }
}

Reconnecting JMS listener

Paul Sterl — Sat, 04 Apr 2020 13:34:15 +0000

Problem

In some projects we still may need to manually to reconnect to our JMS provider. For what ever reason the framework or the container cannot do the job for us. As so we have to ensure that an once registered JMS listener re-register itself if something bad happens.

Note: Check first if your container can handle this for you.

Solution

Well some JmsConnectionFactory already support a re-connection but they are not always very reliable. For instance, the IBM driver supports in theory a reconnect, but it is just a bit buggy.

Well, what is the straight forward solution? The most easiest way is just to register an exception listener with the connection and rebuild the connection from here:

 connection.setExceptionListener((e) -> {
   connection = cf.createConnection();
   session = connection.createSession();
   consumer = session.createConsumer(session.createQueue("FANCY.QUEUE.NAME"));
   consumer.setMessageListener((m) -> {
     System.out.println("onMessage: " + m);
   }
   connection.start();
 });

Not clean but in theory, this is all that we have to do. Of course, we have to handle the state, the old connection and even worse think about a retry if the connection cannot be created immediately again. The last part considering that we have of course also the requirement to stop the connection and avoid race conditions is the hard part.

ReconnectinListener

Let us build a ReconnectingListener step by step. What we have seen above is that we need a way to determine the desired connection state and we have to provide separate methods for connect and disconnect as we will do this more often, in case we have to retry to re-connect again.

Connecting and Disconnecting

Lets us first solve the connect and disconnect problem. The user should be able to:

Have a separate connect method
Store the user desire if we should be connected or not
Have a separate disconnect method
Have a way to clear the resources without to reset the user desire
Have a way to check if the connection is up and running

@RequiredArgsConstructor
static class ReconnectingListener implements MessageListener,  ExceptionListener {
    final JmsConnectionFactory cf;
    final String destinationQueue;
    
    private Connection connection;
    private Session session;
    private MessageConsumer consumer;
    // 1. Have a separate connect method
    public synchronized void connect() throws JMSException {
        // 2. Store the user desire if we should be connected or not
        shouldRun.set(true);
        if (!isConnected()) {
            connection = cf.createConnection();
            session = connection.createSession();
            consumer = session.createConsumer(session.createQueue(destinationQueue));
            consumer.setMessageListener(this); // register us
            connection.setExceptionListener(this); // react on errors
            connection.start();
        }
    }
    // 3. Have a separate disconnect method 
    public synchronized void disconnect() {
        // 2. Store the user desire if we should be connected or not
        shouldRun.set(false);
        clearConnection();
    }
    // 4. Have a way to clear the resources without to reset the user desire
    private synchronized void clearConnection() {
        JmsUtil.close(consumer);
        JmsUtil.close(session);
        JmsUtil.close(connection);
        consumer = null;
        session = null;
        connection = null;
        LOG.debug("Connection cleared and stoped");
   }
   // 5. Have a way to check if the connection is up and running
   public boolean isConnected() {
       return connection != null && consumer != null && session != null;
   }

Reconnect „onException“

Having solved this we have to re-connect back to the JMS Broker if we lose the connection. For this have to implement the ExceptionListener interface as shown above and now to implement onException. The goal here is now:

Clear the old connection to avoid a double registration
Schedule a delayed retry to connect again
Check if we still should be connected
Retry again, if we fail in our retry to connect to the broker

// we need a executer to delay a retry attempt
private final ScheduledExecutorService reconnectScheduler = Executors.newScheduledThreadPool(1);
@Override
public void onException(JMSException exception) {
    // 1. Clear the old connection to avoid a double registration
    clearConnection();
    // 2. Schedule a delayed retry to connect again
    reconnect(5);
}
private void reconnect(final int delay) {            
    reconnectScheduler.schedule(() -> {
        // 3. Check if we still should be connected
        if (shouldRun.get()) {
            try {
                // here we use our connect method from above
                connect();
            } catch (Exception e) {
                // 4. Retry again, if we fail in our retry to connect to the broker
                LOG.info("Reconnect failed, will retry in {}s. {}", delay, e.getMessage());
                clearConnection(); // just for savety
                reconnect(delay);
            }
        }
    }, delay, TimeUnit.SECONDS);
}

That’s it. Basically we solved all basic requirements

Going further

We should of course provide the ability to set a subscription filter and maybe we should just implement the Closeable interface to provide a more modern API. Not to forget that we have now hardcoded that we subscribe always to a queue, means a way to tell the code if it is a topic or not would be too bad. Maybe we should also consider using the JMS 2.x API like:

public synchronized void connectJms2() throws JMSException {
    shouldRun.set(true);
    if (!isConnected()) {
        context = cf.createContext();
        context.setExceptionListener(this);
        context.setAutoStart(true);
        consumer = context.createConsumer(context.createQueue(destinationQueue));
        consumer.setMessageListener(this); // register us
    }
}

Last but not least we could also destroy the executor. Looking forward to a pull request :-).

Java – Pauls Blog

A Bounded, Thread-Safe In-Memory Store for Java

Problem

Solution

Spring Persistent Tasks

Key Features

React & Spring Boot

Problem

Multi-Module project

Root pom.xml

Backend pom.xml

Frontend pom.xml

Ensure the result in the dist folder is compatible to Spring

Going beyond

Add cache control to static react assets

Transaktionsmanagement mit Spring, JPA, Hibernate

Grundlagen Datenbanken | als Entwickler | Datenbank Locks vs Write Ahead | Spring | JPA | Hibernate

Microservices orchestrieren | Workflows | ESB | Event Bus

Datenbank| Transaktionen | Isolationlevel | Locks | Hibernate | JPA | Spring Boot

Quartz integration in Spring

Why Quartz? motivation

Steps for the integration

Configure Quartz Scheduler

Create a timer Job

Add a Spring configuration

Configure the timer

Trigger a job

Create a job

Configure the job

Trigger the job

Testing it

Alternatives

Links

JPA Model testing with Hibernate Statistics

Problem

In your test

Reconnecting JMS listener

Problem

Solution

ReconnectinListener

Connecting and Disconnecting

Reconnect „onException“

Going further

Links