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 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.

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 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.

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.