Serguey Asael Shinder: Hibernate 7.4.11 stops dropping ON CONFLICT DO NOTHING on H2, Oracle and SQL Server
Hibernate ORM 7.4.11.Final was published on 27 September. The release announcement points to the issue tracker for the changes, and the list for this version has four bug fixes. One of them is the kind of bug I find worst: a clause that was accepted and then silently ignored.
The dropped clause. HQL supports insert ... on conflict (...) do nothing, which is how you write an idempotent insert-if-absent. According to HHH-20826, the SQL translators for H2, Oracle and SQL Server discarded the conflict clause when its action was do nothing and rendered a plain INSERT. The code even carried a comment acknowledging that this would "possibly run into unique constraint violation", which is exactly what the clause exists to prevent. The do update variant was already emulated with a MERGE statement that handled both cases; the fix sends do nothing down the same path when conflict columns are given. PostgreSQL, which supports the clause natively, and MySQL and MariaDB, where Hibernate emits INSERT ... ON DUPLICATE KEY UPDATE, were not affected.
The report came from Keycloak, which uses the pattern for concurrent writes such as login failure tracking and creating a root authentication session if one does not exist. On the three affected databases those queries produced duplicate key violations under load instead of doing nothing. The issue lists 6.6.57, 7.4.8 and 8.0.0.Beta1 among the affected versions.
A second concurrency fix. HHH-20894 covers StatelessSession.upsert and upsertMultiple: when two transactions upserted the same row, one could insert while the other, after waiting for it, did nothing instead of retrying as an update, so the second transaction's data could be lost. The other two fixes in the release are Interceptor#onLoad not being called for a StatelessSession, and enum-as-string join columns in a composite primary key.
What it means
If your application relies on on conflict do nothing and you test on PostgreSQL but run on Oracle or SQL Server, or the reverse, you may have been seeing constraint violations you attributed to a race in your own code. The general lesson is the one the Hibernate comment made visible: a dialect that cannot express a clause should emulate it or refuse it. Quietly rendering something weaker turns a portability gap into a production incident that only shows up under concurrency.