when duplicate entry error is given from the database, a internal java.sql.SQLIntegrityConstraintViolationException is thrown with SQLState="2300" and errorCode=1062.

when running this insert queries in batch mode, this exception is wrapped in BatchUpdateException. This exception doesn't inherited the original SQLState and errorCode from the SQLIntegrityConstraintViolationException.

Hibernate receives the BatchUpdateException and tries to map this to more generic , hibernate specific , ConstraintViolationException
using the SQLStateConversionDelegate class.

This flow worked until upgrade to 3.0.6 because the BatchUpdateException has SQLState=null which cause Hibernate to skip the mapping to ConstraintViolationException. Hibernate use the than "first" active Exception , which is the BatchUpdateException !

from user perspective , we have code to handle duplicate exception which catch the hibernate ConstraintViolationException , as we have generic spring boot Repository based code using different DB vendors.

Attached you see a debug session with BatchUpdateException with SQLState=null and underlying SQLIntegrityConstraintViolationException with valid SQLState and vendorCode

the 2.7.5 JDBC driver the BatchUpdateException is created with same SQLState & errorCode as the original SQLException , so hibernate doesn't need to "deep" investigate the possible chain of causes .

a solution , tested this with some reflection code , is to copy the SQLState & errorCode from the SQLIntegrityConstraintViolationException to BatchUpdateException when creating BatchUpdateException in ExceptionFactory.createBatchUpdate()

return new BatchUpdateException(sqlException.toString(),sqlException.getSQLState(),sqlException.getErrorCode(),updateCounts, sqle)