I agree that making this change would be very wrong, as we would be potentially catching any RunTimeException and returning null as if "not present in the database" was the case. I opened this jira as part of the work on CTS-182 (which questioned why EntityManager.find() doesn't return null when the DataSource.getConnect() throws an exception because the transaction is marked for roll back only).
The question for CTS-182 has evolved into asking why DataSource.getConnection() is throwing an exception which I still think is allowable (as per OTS/JTA specs and java doc for Java Transaction). In this particular case, the application threw a RuntimeException in a prePersist callback which leads to the Transaction being marked for rollback only. The application code then purposely calls em.find() which is throwing:
javax.persistence.PersistenceException => org.hibernate.exception.GenericJDBCException => java.sql.SQLException => javax.resource.ResourceException => javax.resource.ResourceException
I think it is pretty cool that our DataSource.getConnection() is taking a fail-fast action since the only possible outcome is for the (marked for rollback) transaction to be rolled back.
|