-
Bug
-
Resolution: Unresolved
-
Major
-
None
-
1.5.10.Final
-
None
After switching from Wildfly 26 to Wildfly 29 we suffered a breakdown of the scalability of batches in our application running against DB2 and Oracle. PostgreSQL was not affected.
Running a batch with a parallelity of 32 the performance deteriorated by 10%, when running with a parallelity of 128 the batches were hardly faster than with a parallelity of 32 and took between 3.5 to 4 times longer than usual.
Eventmonitors from DB2 showed that the DB2 (shown in DB-Mon-26.png and DB-Mon-29.png) had to describe and prepare many more SQL-Statements than before.
The Statement-Cache view of the Wildfly-console indicates that the reason is the different behaviour of the statement-cache which deletes a lot of SQL-Statements in Wildfly 29 while not deleting any in Wildfly 26. (See StmtCache_26.png and StmtCache_29.png).
We detected Issue JBJCA-1461, downloaded the commit from GitHub and managed to compile the code with reverted changes. After patching the ironjacamar-jdbc-3.0.3.Final.jar module with the newly compiled class the behaviour of the Statement-Cache was back to what we are used to and the batch-times are also "normal" again.