向 Spring 官方提交了一个 Issue

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

A method that opens a transaction calls another method that starts a new transaction，if all connections are exhausted before the last new transaction method is executed,then all threads in the process will block，this process will fail.

Pseudo code：

@Transactional
methodA(){
    // All the threads that started the transaction were executed here, but the connection was exhausted.
    // The latter method execution will get a new connection,but it will never get it.
    @Transactional(propagation=Propagation.REQUIRES_NEW)
    methodB(){
    }
}

1

It's not forum here, if you think it's a bug please paste test case, if you think it's an improvement please submit PR, end of discussion.

1

Sorry, I didn't make it clear. This is the test code, where it blocks the real process. Methodb() will never execute.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

@slf4j
@service
public class PropagationExampleServiceImpl implements PropagationExampleService {
@Autowired
PropagationExampleService service;

@Transactional
@Override
public void methodA() throws InterruptedException {
	Thread.sleep(100);
	log.info("methodA");
	service.methodB();
}

@Transactional(propagation = Propagation.REQUIRES_NEW)
@Override
public void methodB() throws InterruptedException {
	log.info("methodB");
	Thread.sleep(100);
}
}

@SpringBootTest
public class PropagationExampleServiceTest {
@Autowired
PropagationExampleService service;
ExecutorService executor = new ThreadPoolExecutor(10, 10, 60,
TimeUnit.SECONDS, new ArrayBlockingQueue<>(1000));

@Test
public void methodATest() {
	for (int i = 0; i < 20; i++) {
		executor.execute(() -> {
			try {
				service.methodA();
			} catch (InterruptedException e) {
				e.printStackTrace();
			}
		});
	}
	LockSupport.park();
}
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

spring:
datasource:
name: druidDataSource
type: com.alibaba.druid.pool.DruidDataSource
druid:
max-active: 10

Here is the log:
2020-12-11 10:15:56.385 INFO 10864 --- [pool-1-thread-1] c.j.s.s.i.PropagationExampleServiceImpl : methodA
2020-12-11 10:15:56.385 INFO 10864 --- [pool-1-thread-2] c.j.s.s.i.PropagationExampleServiceImpl : methodA
2020-12-11 10:15:56.385 INFO 10864 --- [pool-1-thread-5] c.j.s.s.i.PropagationExampleServiceImpl : methodA
2020-12-11 10:15:56.385 INFO 10864 --- [pool-1-thread-6] c.j.s.s.i.PropagationExampleServiceImpl : methodA
2020-12-11 10:15:56.385 INFO 10864 --- [pool-1-thread-8] c.j.s.s.i.PropagationExampleServiceImpl : methodA
2020-12-11 10:15:56.385 INFO 10864 --- [pool-1-thread-9] c.j.s.s.i.PropagationExampleServiceImpl : methodA
2020-12-11 10:15:56.385 INFO 10864 --- [pool-1-thread-3] c.j.s.s.i.PropagationExampleServiceImpl : methodA
2020-12-11 10:15:56.385 INFO 10864 --- [ool-1-thread-10] c.j.s.s.i.PropagationExampleServiceImpl : methodA
2020-12-11 10:15:56.385 INFO 10864 --- [pool-1-thread-7] c.j.s.s.i.PropagationExampleServiceImpl : methodA
2020-12-11 10:15:56.385 INFO 10864 --- [pool-1-thread-4] c.j.s.s.i.PropagationExampleServiceImpl : methodA

1
2

I think the result is expected, you should increase max-active > concurrency, so If you change max-active to 21, it will pass, waiting for your confirmation.
You should set a max-wait on dataSource, then getConnection will timeout instead of endless blocking.

1
2
3
4
5

I know, I just want to express that. In fact, the number of connections in the connection pool is generally not large. In the above example, only one layer is nested. If there are multiple layers of newly started transactions in the code, only a small amount of concurrency is needed to trigger the above result.

I just think that when multiple threads compete for resources, each thread must grab multiple resources before ending the task, which may be a hidden danger.

Because this method may cause multiple threads to rob only a part of the resources they need. They can't release what they have acquired without getting all the resources they need. By this time, however, resources have been exhausted.

1
2

Your test blocked because you didn't set timeout for ds.getConnection(), for example maxWait for druid and connectionTimeout for HikariCP.
It's really nothing to do with spring transaction.

1
2
3
4
5
6
7
8
9

I'm sorry to have taken you so long.

I just want to put forward what I think may be hidden dangers. It's not that I have encountered problems in use. I just don't quite understand why this place is designed in this way.

Even if Max wait is set here, the above situation may occur. It's just going to wait for a while, not the whole process, but it's bad enough.

For this reason, I choose to avoid using REQUIRES_NEW, if I need to start a new transaction in a method, I will use asynchronous or transactionSynchronization.afterCommit ()。

You may say that the outer method will not be able to sense the exception, but why should it? These are two transactions. If I need the outer layer to sense the inner layer's anomaly, I can use NESTED.

1
2

I admit your title "Propagation.REQUIRES_NEW May cause all connections to be occupied".
application should deal REQUIRES_NEW properly, there is no bug or improve space here, at most adding note in docs. Do you agree?