#10045: Enable JDBC test cases with TestContainers approach

[mjd507]

I really don't have any better ways to enable those JDBC concurrent test cases back :(

for AbstractTxTimeoutMessageStoreTests, there are two pollers impact the performance, first poller using custom task-executor with 100 threads run with fixed-rate 200, second poller with default executor run with fixed-delay 100.

for Mysql/Oracle, I increase the fixed-rate from 200 to 2000, and fixed-delay from 100 to 1000.

[artembilan]

So, this idCache logic is really unstable, not just with Derby:

2025-05-30 14:28:19,403 ERROR [pool-207-thread-2] [org.springframework.integration.jdbc.store.channel.MySqlTxTimeoutMessageStoreTests] - IdCache race condition.
org.springframework.dao.CannotAcquireLockException: PreparedStatementCallback; SQL [DELETE from INT_CHANNEL_MESSAGE where MESSAGE_ID=? and GROUP_KEY=? and REGION=?]; Deadlock found when trying to get lock; try restarting transaction
	at org.springframework.jdbc.support.SQLExceptionSubclassTranslator.doTranslate(SQLExceptionSubclassTranslator.java:78) ~[spring-jdbc-6.2.7.jar:6.2.7]
	at org.springframework.jdbc.support.AbstractFallbackSQLExceptionTranslator.translate(AbstractFallbackSQLExceptionTranslator.java:107) ~[spring-jdbc-6.2.7.jar:6.2.7]
	at org.springframework.jdbc.core.JdbcTemplate.translateException(JdbcTemplate.java:1556) ~[spring-jdbc-6.2.7.jar:6.2.7]
	at org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:677) ~[spring-jdbc-6.2.7.jar:6.2.7]
	at org.springframework.jdbc.core.JdbcTemplate.update(JdbcTemplate.java:972) ~[spring-jdbc-6.2.7.jar:6.2.7]
	at org.springframework.jdbc.core.JdbcTemplate.update(JdbcTemplate.java:1016) ~[spring-jdbc-6.2.7.jar:6.2.7]
	at org.springframework.jdbc.core.JdbcTemplate.update(JdbcTemplate.java:1021) ~[spring-jdbc-6.2.7.jar:6.2.7]
	at org.springframework.integration.jdbc.store.JdbcChannelMessageStore.doRemoveMessageFromGroup(JdbcChannelMessageStore.java:627) ~[main/:?]
	at org.springframework.integration.jdbc.store.JdbcChannelMessageStore.pollMessageFromGroup(JdbcChannelMessageStore.java:544) ~[main/:?]
	at org.springframework.integration.jdbc.store.channel.AbstractTxTimeoutMessageStoreTests.lambda$testInt2993IdCacheConcurrency$0(AbstractTxTimeoutMessageStoreTests.java:160) ~[test/:?]
	at org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:140) ~[spring-tx-6.2.7.jar:6.2.7]
	at org.springframework.integration.jdbc.store.channel.AbstractTxTimeoutMessageStoreTests.lambda$testInt2993IdCacheConcurrency$1(AbstractTxTimeoutMessageStoreTests.java:157) ~[test/:?]
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) [?:?]
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) [?:?]
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) [?:?]
	at java.base/java.lang.Thread.run(Thread.java:840) [?:?]
Caused by: com.mysql.cj.jdbc.exceptions.MySQLTransactionRollbackException: Deadlock found when trying to get lock; try restarting transaction
	at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:115) ~[mysql-connector-j-9.3.0.jar:9.3.0]
	at com.mysql.cj.jdbc.exceptions.SQLExceptionsMapping.translateException(SQLExceptionsMapping.java:114) ~[mysql-connector-j-9.3.0.jar:9.3.0]
	at com.mysql.cj.jdbc.ClientPreparedStatement.executeInternal(ClientPreparedStatement.java:990) ~[mysql-connector-j-9.3.0.jar:9.3.0]
	at com.mysql.cj.jdbc.ClientPreparedStatement.executeUpdateInternal(ClientPreparedStatement.java:1168) ~[mysql-connector-j-9.3.0.jar:9.3.0]
	at com.mysql.cj.jdbc.ClientPreparedStatement.executeUpdateInternal(ClientPreparedStatement.java:1103) ~[mysql-connector-j-9.3.0.jar:9.3.0]
	at com.mysql.cj.jdbc.ClientPreparedStatement.executeLargeUpdate(ClientPreparedStatement.java:1450) ~[mysql-connector-j-9.3.0.jar:9.3.0]
	at com.mysql.cj.jdbc.ClientPreparedStatement.executeUpdate(ClientPreparedStatement.java:1086) ~[mysql-connector-j-9.3.0.jar:9.3.0]
	at org.apache.commons.dbcp2.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:137) ~[commons-dbcp2-2.13.0.jar:2.13.0]
	at org.apache.commons.dbcp2.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:137) ~[commons-dbcp2-2.13.0.jar:2.13.0]
	at org.springframework.jdbc.core.JdbcTemplate.lambda$update$2(JdbcTemplate.java:977) ~[spring-jdbc-6.2.7.jar:6.2.7]
	at org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:658) ~[spring-jdbc-6.2.7.jar:6.2.7]

😢

Not sure what to suggest.

We probably review your PR and accept it as is.
I have some idea what could be tightened in that idCache algorithm, but that's already out of this task scope.

Thanks

[mjd507]

thank you, all those test cases passed in my local, both individual test classes and whole jdbc integration tests. I didn't add LongRunningTest for them now, but I think we need. possibly add @Disabled back again .

after reviewing or testing, if any changes required, can help me to change it directly ?
thanks again

[artembilan]

Re-running PR build...
Please, consider in the future to create branches for feature to issue PRs against them.
Right now this one is against your main.
That would cause some routine when this is merged and you would need to force update your local main.

Pulling also your changes locally for final review...

Thanks.

[mjd507]

That would cause some routine when this is merged and you would need to force update your local main.

Sure, nice suggestion！
Currently after every PR merged, I manually reset --hard to a previous upstream version in my local, and pull latest version from upstream again. hmm.. Just only want to keep only one branch. regarding my remote branch, I often push with -f , it's sometimes dangerous.

Will try new a feature branch in future and see.

[artembilan]

Merging.
The timing is OK for these new tests: no need for long-running.
We will disable those tests which are not stable according to our experience.
For now we can live with whatever we have so far.

Thank you!

[artembilan]

FYI, the snapshot against your change is green: https://github.com/spring-projects/spring-integration/actions/runs/15350770171/job/43198145399 🤷