`@ConcurrencyLimit` weird behavior when combined with `@Async` and `@Transactional`

[vpavic]

I'm seeing some weird behavior when attempting to combine the 3 annotations from the subject, for example:

@Async
@ConcurrencyLimit(1)
@Transactional
void doWork() throws Exception {
    logger.info("Starting work");
    Thread.sleep(Duration.ofSeconds(10));
    logger.info("Finished work");
}

On the first two invocations of such method, @ConcurrencyLimit doesn't appear to work, but from there on it starts working OK. Here's the log output I'm seeing after invoking the service 3 times after startup, with invocations being about a second apart:

2025-11-10T13:15:44.224+01:00  INFO 906182 --- [         task-1] com.example.SampleService                : Starting work
2025-11-10T13:15:45.766+01:00  INFO 906182 --- [         task-2] com.example.SampleService                : Starting work
2025-11-10T13:15:54.225+01:00  INFO 906182 --- [         task-1] com.example.SampleService                : Finished work
2025-11-10T13:15:55.767+01:00  INFO 906182 --- [         task-2] com.example.SampleService                : Finished work
2025-11-10T13:15:55.768+01:00  INFO 906182 --- [         task-3] com.example.SampleService                : Starting work
2025-11-10T13:16:05.769+01:00  INFO 906182 --- [         task-3] com.example.SampleService                : Finished work

Removing @Transactional from the mix makes everything work as expected. I'll attach a reproducer shortly.

mre-spring-framework-35788.zip

[jhoeller]

For a start, this works fine for me in a local Spring Framework integration test. I'll see what difference the Boot setup in the provided repro makes.

[mdeinum]

Additionally, I ran a quick test, making the method public in the service makes it work as well.

[jhoeller]

Hmm, in my local integration test, it works with and without public modifiers on the service class and method. Diving into the Boot setup in a moment here.

[jhoeller]

I cannot reproduce this in the provided Boot setup either. @vpavic could you try to double-check what exactly is happening for you in a local run there?

[vpavic]

Adding logging.level.org.springframework.aop.interceptor.ConcurrencyThrottleInterceptor=debug to application.properties, starting the sample and then issuing 3 GET / requests with second apart of each other yields this:

2025-11-10T15:26:05.349+01:00 DEBUG 919406 --- [         task-1] o.s.a.i.ConcurrencyThrottleInterceptor   : Entering throttle at concurrency count 0
2025-11-10T15:26:05.354+01:00  INFO 919406 --- [         task-1] com.zaxxer.hikari.HikariDataSource       : HikariPool-1 - Starting...
2025-11-10T15:26:05.559+01:00  INFO 919406 --- [         task-1] com.zaxxer.hikari.pool.HikariPool        : HikariPool-1 - Added connection conn0: url=jdbc:h2:mem:67c55b76-1ffd-45e9-af37-0ff9e8a3a4b2 user=SA
2025-11-10T15:26:05.561+01:00  INFO 919406 --- [         task-1] com.zaxxer.hikari.HikariDataSource       : HikariPool-1 - Start completed.
2025-11-10T15:26:05.569+01:00  INFO 919406 --- [         task-1] com.example.SampleService                : Starting work
2025-11-10T15:26:06.915+01:00 DEBUG 919406 --- [         task-2] o.s.a.i.ConcurrencyThrottleInterceptor   : Entering throttle at concurrency count 0
2025-11-10T15:26:06.915+01:00  INFO 919406 --- [         task-2] com.example.SampleService                : Starting work
2025-11-10T15:26:08.628+01:00 DEBUG 919406 --- [         task-3] o.s.a.i.ConcurrencyThrottleInterceptor   : Concurrency count 1 has reached limit 1 - blocking
2025-11-10T15:26:15.570+01:00  INFO 919406 --- [         task-1] com.example.SampleService                : Finished work
2025-11-10T15:26:15.579+01:00 DEBUG 919406 --- [         task-1] o.s.a.i.ConcurrencyThrottleInterceptor   : Returning from throttle at concurrency count 0
2025-11-10T15:26:16.916+01:00  INFO 919406 --- [         task-2] com.example.SampleService                : Finished work
2025-11-10T15:26:16.917+01:00 DEBUG 919406 --- [         task-2] o.s.a.i.ConcurrencyThrottleInterceptor   : Returning from throttle at concurrency count 0
2025-11-10T15:26:16.917+01:00 DEBUG 919406 --- [         task-3] o.s.a.i.ConcurrencyThrottleInterceptor   : Entering throttle at concurrency count 0
2025-11-10T15:26:16.918+01:00  INFO 919406 --- [         task-3] com.example.SampleService                : Starting work
2025-11-10T15:26:26.918+01:00  INFO 919406 --- [         task-3] com.example.SampleService                : Finished work
2025-11-10T15:26:26.919+01:00 DEBUG 919406 --- [         task-3] o.s.a.i.ConcurrencyThrottleInterceptor   : Returning from throttle at concurrency count 0

What I missed originally is that data source initialization happens in task-1 thread on first invocation of service. Do your attempts at reproducing this also include such sequence?

[jhoeller]

I see the same sequence but instead of task2 entering the throttle again at concurrency count 0, I see two "Concurrency count 1 has reached limit 1 - blocking" lines from task-2 as well as task-3. So while it's similar to your log, I still cannot reproduce the oddity.

My impression is that this could be a race condition in the initialization of the per-method ConcurrencyThrottleInterceptor instance that holds the current count, initially using two such ConcurrencyThrottleInterceptor instances for the same method but then continuing to use the same cached instance from the third call onwards. This instance management happens in ConcurrencyLimitBeanPostProcessor.ConcurrencyLimitInterceptor, so I suppose we'll have to review the nuances there.

[jhoeller]

At the moment, I fail to see an obvious race condition in ConcurrencyLimitBeanPostProcessor.ConcurrencyLimitInterceptor. Any hints or educated guesses welcome, also toward other potential causes for the behavior observed by @vpavic...