[rzo1]

The first scheduled run of the new Databases workflow was red on MariaDB 11.8: the criteria package failed in bulk and the connection pool was then exhausted, TestMultiselect spending 170s purely on Timeout waiting for idle object. Both problems are in the test suite, on master, and independent of each other — no production code changes here. Two commits so they can be reviewed apart.

1. Two unrelated CompUser hierarchies defaulted to the same table. o.a.o.persistence.criteria.CompUser and o.a.o.persistence.common.apps.CompUser both map to CompUser with incompatible columns, so whichever package runs second makes SynchronizeMappings=buildSchema(SchemaAction=drop,add) rewrite the table on every EntityManagerFactory — and CriteriaTest builds one per test method. MariaDB's general query log shows 105 ALTER TABLE CompUser DROP COLUMN in a single test class. MariaDB keeps dropped columns in the clustered-index record format, so they keep counting towards the 8126-byte row limit until ERROR 1118 Row size too large. A pure-SQL replay of those 14 statements fails at cycle 14 on mariadb:11.8 and 11.4, while mysql:8.0 survives 25 cycles — which is exactly why the MySQL job was green on the same suite. Fix: an explicit @Table(name = "CMN_COMPUSER") on the common/apps fixture. The entity name is untouched, so both the jpql tests' JPQL and the criteria tests' expected SQL stay valid.

Why it never showed locally: surefire's default runOrder=filesystem. On the Linux runner jpql runs before criteria; on macOS the reverse. Measured on mariadb:11.8 in CI order, on a fresh database — the jpql phase is 123 tests and green either way, the criteria phase goes from 540 tests / 133 failures / 183 errors (513 of them Row size too large) to 544 / 0 / 0.

2. A failure in setUp left a connection in the pool for good. junit.framework.TestCase.runBare() calls setUp() outside its try/finally, so a failure there skips tearDown() entirely. CriteriaTest.setUp() opens an EntityManager, and subclasses begin a transaction in their own setUp(), which makes the store manager retain a JDBC connection; CriteriaTest.emf is static and shared by all 24 criteria classes, so each failure leaked one connection out of a pool sized MaxTotal=10. About a dozen failures emptied it, and everything downstream then failed with a pool timeout instead of its own problem. AbstractCriteriaTestCase.runBare() now runs setUp() inside the guarded block and calls tearDown() exactly once either way (what JUnit 4 does for @Before/@After), and CriteriaTest.tearDown() is made null- and exception-safe, since an exception out of em.close() previously skipped emf.close() and leaked the whole pool. Raising MaxTotal or the wait timeout would only postpone the symptom, so the profiles are left alone.

Both new tests fail without their change (verified by reverting each in a throwaway worktree). The MariaDB row-format behaviour is user-facing on its own — an application using buildSchema(drop,add) or mappingtool -action refresh hits the same rotation — so it is documented in supported_databases.xml, with the remedy.

Verified: criteria + jpql packages 667/0/0 on both Derby and H2; on mariadb:11.8 as above.

The third item in the ticket, TestPessimisticLocks on PostgreSQL, is not in this PR. A change for it was written and then dropped: the test passes 6/6 on postgres:11 on repeated runs here, the failure could not be reproduced, and the justification quoted SQL (... FOR UPDATE) that does not appear in the captured statements at all. It is order-dependent in principle — the ranged query carries no ORDER BY, so setFirstResult(1) skips whichever row the server returns first — but that belongs with OPENJPA-3000, which already tracks lock-manager flakes on PostgreSQL and Oracle, and needs a reproduction before a fix.

[solomax]

maybe this "cascade" can be breaked into several private methods to improve readability?

[solomax]

do we need addSuppressed here?

[solomax]

it seems weekly build waits for this one to pass :)