JPA StorageService fails badly with case-insensitive tables

Some days ago I experienced an anomaly in Shibboleth IdP behavior. In fact, when a user that: 1) had already performed un authetication in the past and 2) also had approved the terms-of-use (that are stored in the StorageRecords table in the shibboleth database), try to authenticate using a wrong username (in which he mix of lowercase and uppercase character), using a browser that support a default language that are different from the one used when he have accepted the terms-of-use, we experienced an anomaly.
Specifically, the Authentication succeeded always because the IdP automatically convert al the character in lowercase (and this is correct), but the same behavior doesn't occurs when the username is used from "intercept/terms-of-use" as a database key (so, in fact, it remains a mix of lowercase with uppercase). This situation causes an HibernateExecepion, of the type "Error committing transaction" and the subsequent losing of the db connection (we use a JPAStorageService).

So, because for our privacy policy GDPR compliant, we use a StoredPersistentIdGenerator strategy, nobody can authenticate after this event.
If we use the status.sh script we can see that all the shibboleth services are running (in fact we can notice an error only when we force the reload of the service "shibboleth.NameIdentifierGenerationService").

Definitely, in order to reactivate the IdP's operation we must restart the Jetty service.

Currently I have modified the "simple-subject-c14n-config.xml" files in orter to force, after the authentication, the username's lowercase transformation (I have used the following syntax: <util:constant static-field="java.lang.Boolean.TRUE" id="shibboleth.c14n.simple.Lowercase"/>).
This protects us from errors in typing the username, but I fear that the problem may be more general

So, I'm worried that another case can be determined that causes a committing transaction error, resulting in the loss of the connection to the database. In fact, I would expect that as a result of an error the connection will be restored anyway, without the need to restart the Jetty service.