[
https://issues.apache.org/jira/browse/OPENJPA-3016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18126730#comment-18126730
]
ASF subversion and git services commented on OPENJPA-3016:
----------------------------------------------------------
Commit 302bcc72ca1c4f5ebf49c46d1d6682fdff329e63 in openjpa's branch
refs/heads/OPENJPA-3016 from Richard Zowalla
[ https://gitbox.apache.org/repos/asf?p=openjpa.git;h=302bcc72c ]
[OPENJPA-3016] Give the common/apps CompUser fixture its own table
Two unrelated entity hierarchies in the test suite were rooted at a class
called CompUser - org.apache.openjpa.persistence.criteria.CompUser and
org.apache.openjpa.persistence.common.apps.CompUser - and both defaulted to
a table of that name, with incompatible columns: userid is NOT NULL in one
and nullable in the other, ADD_ID is BIGINT in one and INTEGER in the other,
and only the common/apps one has nameAsLob.
Whichever package runs second therefore makes
SynchronizeMappings=buildSchema(SchemaAction='drop,add') rewrite the table:
seven ALTER TABLE ... DROP COLUMN followed by seven ALTER TABLE ... ADD, on
every EntityManagerFactory it creates. CriteriaTest creates and closes one
factory per test method, so a single criteria class rotates every column of
CompUser dozens of times.
MariaDB executes such an ADD/DROP COLUMN instantly and keeps the dropped
columns in the clustered index record format, counting them towards the
8126 byte maximum row size. After about a dozen rotations the next statement
is rejected:
ALTER TABLE CompUser ADD DTYPE VARCHAR(255)
ERROR 1118 (42000): Row size too large. The maximum row size for the used
table type, not counting BLOBs, is 8126.
This is the server's behaviour, not a defect in OpenJPA or in its MariaDB
dictionary: replaying the same fourteen statements by hand against an
otherwise untouched InnoDB table fails on the fourteenth cycle, while
information_schema still reports the eight visible columns. MySQL 8.0 does
not accumulate the metadata, which is why the scheduled Databases run was
red only for MariaDB.
Nothing about the collision is MariaDB specific, though, so the fixture is
separated rather than the dictionary taught to tolerate it: an explicit
@Table(name = "CMN_COMPUSER") keeps the two hierarchies apart and makes the
suite independent of the order in which surefire happens to list the test
classes - which is what hid this locally, where the criteria package runs
before the jpql one.
The entity name is unchanged, so the JPQL in the jpql tests ("FROM CompUser
o") and the expected SQL in the criteria tests (which names the table
CompUser) both stay as they are.
Reproduced on mariadb:11.8 by running the jpql expressions and functions
packages first and the criteria package second, on a freshly created
database: the jpql phase is 123 tests and green either way, and the criteria
phase goes from 540 tests with 133 failures and 183 errors, 513 of them
reporting "Row size too large", to 544 tests with none. The new test states the
invariant directly and fails without the change.
The MariaDB behaviour is user facing on its own, independent of the test
suite: an application configured with
SynchronizeMappings=buildSchema(SchemaAction='drop,add'), or a deployment
script running mappingtool -action refresh, rotates the same columns on every
restart and eventually fails the same way on a table whose visible columns fit
comfortably inside the limit, with nothing in information_schema to hint at
it. It is therefore written up as a third item under "Known issues with
MariaDB" in supported_databases.xml, naming the remedies - rebuild the table
with ALTER TABLE ... FORCE or OPTIMIZE TABLE, or do not use a drop/add schema
action against a long-lived MariaDB schema - and cross referencing the runtime
forward mapping section. The file is still well formed: xmllint --noout
openjpa-project/src/doc/manual/supported_databases.xml.
> Criteria tests fail on MariaDB and exhaust the connection pool;
> TestPessimisticLocks fails on PostgreSQL
> --------------------------------------------------------------------------------------------------------
>
> Key: OPENJPA-3016
> URL: https://issues.apache.org/jira/browse/OPENJPA-3016
> Project: OpenJPA
> Issue Type: Bug
> Components: jpa
> Reporter: Richard Zowalla
> Priority: Major
>
> The first scheduled run of the Databases workflow (OPENJPA-3011) was red: run
> 38204987477 of 12 Oct 2026 on master.
> check success
> build (Java 21, test-mysql-docker) success
> build (Java 21, test-postgresql-docker) failure
> build (Java 21, test-mariadb-docker) failure
> PostgreSQL 11: 197 tests, 1 failure,
> org.apache.openjpa.persistence.lockmgr.TestPessimisticLocks.
> MariaDB 11.8: the criteria package fails in bulk, starting about three
> minutes into the run, e.g.
> TestTypesafeCriteria 124 run, 45 failures, 70 errors
> TestMetaModelTypesafeCriteria 29 run, 10 failures, 11 errors
> TestTypeSafeCondExpression 55 run, 9 failures, 27 errors
> TestSubqueries 28 run, 13 failures, 15 errors
> TestQueryByExample 7 run, 1 failure, 6 errors
> and later, after those failures, the connection pool is exhausted:
> org.apache.openjpa.persistence.PersistenceException: Cannot get a
> connection, pool error Timeout waiting for idle object,
> maxWaitDuration=PT9.999990575S
> Caused by: java.util.NoSuchElementException: Timeout waiting for idle object
> TestMultiselect then reports 28 errors in 170 seconds, all of them connection
> timeouts.
> The ordering suggests the pool exhaustion is a consequence rather than the
> cause: the criteria tests fail first for some dictionary reason, and the
> failures leak connections until the pool is empty. That needs confirming, and
> both the dictionary failures and the leak are worth fixing - a test whose
> failure path leaks a connection turns one red test into a red suite.
> To reproduce, start the server yourself, since the docker profiles do not
> start containers during mvn test:
> docker run -d --name ojpa-maria -e MARIADB_DATABASE=openjpatst -e
> MARIADB_ROOT_PASSWORD=openjpatst -p 3306:3306 mariadb:11.8
> mvn -Ptest-mariadb-docker -pl openjpa-persistence-jdbc -am test
> -Dtest='org/apache/openjpa/persistence/criteria/Test*.java'
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
