[hibernate-issues] [Hibernate-JIRA] Resolved: (HHH-7251) PostgreSQL Dialect not properly mapping SQL error codes for pessimistic lock exceptions.

[Strong Liu (JIRA)]

     [ https://hibernate.onjira.com/browse/HHH-7251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Strong Liu resolved HHH-7251.
-----------------------------

       Resolution: Fixed
    Fix Version/s: 4.1.3

patch applied with a minor change, thanks

> PostgreSQL Dialect not properly mapping SQL error codes for pessimistic lock exceptions.
> ----------------------------------------------------------------------------------------
>
>                 Key: HHH-7251
>                 URL: https://hibernate.onjira.com/browse/HHH-7251
>             Project: Hibernate ORM
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 3.6.10, 4.1.2
>         Environment: PostgreSQL
>            Reporter: Bryan Varner
>            Assignee: Strong Liu
>             Fix For: 4.1.3
>
>         Attachments: Postgres91Dialect.java
>
>   Original Estimate: 20m
>  Remaining Estimate: 20m
>
> Using Hibernate-entitymanager in a JPA 2.0 environment,
> {code}
> Map<String, Object> params = new HashMap<String, Object>();
> params.put("javax.persistence.lock.timeout", 0);
> entityManager.find(Foo.class, id, LockModeType.PESSIMISTIC_WRITE, params);
> {code}
> Will emit the proper SQL (with FOR UPDATE NOWAIT), however if the lock is not available, it results in throwing PersistenceException instead of PessimisticLockException or LockTimeoutException.
> I see that the SQL exception mapping code seems to be in a state of flux, where more of the handling is being pushed into delegates provided by the respective dialects. I highly approve of this approach, however it doesn't help me, since my transactions are being marked rollback only when a recoverable lock error (timeout) occurs.
> I'm attaching my solution, which is a quick and dirty custom dialect which properly maps PostgreSQL lock exceptions back to the proper Hibernate exceptions, which are then translated into the proper JPA exceptions.
> I know this issue existed in 3.6.10 (which is why I upgraded to 4.1.2 today). I do not know if the dialect-specific bits are in 3.6, but it appears the 'old' location for these types of error-code checks are in the SQLStateConversionDelegate, they could easily be added there.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira