3

We are developing a Web application with:

  • JPA (Hibernate 4.2.11.Final)
  • Hibernate Validator (JSR-303)
  • JTA
  • Two persistence units with two different Datasources
  • Deploys in a JBOSS EAP 6.2

Our EntityManagers are both configured in a Spring configuration file with the next relevant properties:

<prop key="hibernate.transaction.jta.platform">
  org.hibernate.service.jta.platform.internal.JBossAppServerJtaPlatform
</prop>
<prop key="hibernate.dialect">org.hibernate.dialect.Oracle10gDialect</prop>
<!-- validate | update | create | create-drop -->
<prop key="hibernate.hbm2ddl.auto">validate</prop>
<prop key="hibernate.show_sql">true</prop>
<prop key="hibernate.format_sql">false</prop>
<prop key="javax.persistence.transactionType">JTA</prop>
<prop key="javax.persistence.validation.mode">AUTO</prop>

Also declaring transaction manager in Spring

  <tx:jta-transaction-manager />

The problem is that in certain service calls (only a few) when a ConstaintViolationException is thrown it is somehow replaced by a chain of exceptions logged like the following:

18:34:54,334 INFO [stdout] (http-localhost/127.0.0.1:8080-6) java.sql.SQLException: javax.resource.ResourceException: IJ000460: Error checking for a transaction 18:34:54,334 INFO [stdout] (http-localhost/127.0.0.1:8080-6) at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:147) 18:34:54,334 INFO [stdout] (http-localhost/127.0.0.1:8080-6) at org.hibernate.ejb.connection.InjectedDataSourceConnectionProvider.getConnection(InjectedDataSourceConnectionProvider.java:70) ... 18:34:54,340 INFO [stdout] (http-localhost/127.0.0.1:8080-6) Caused by: javax.resource.ResourceException: IJ000460: Error checking for a transaction 18:34:54,340 INFO [stdout] (http-localhost/127.0.0.1:8080-6) at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:362) 18:34:54,340 INFO [stdout] (http-localhost/127.0.0.1:8080-6) at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:464) 18:34:54,340 INFO [stdout] (http-localhost/127.0.0.1:8080-6) at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:139) 18:34:54,340 INFO [stdout] (http-localhost/127.0.0.1:8080-6) ... 111 more 18:34:54,340 INFO [stdout] (http-localhost/127.0.0.1:8080-6) Caused by: javax.resource.ResourceException: IJ000459: Transaction is not active: tx=TransactionImple < ac, BasicAction: 0:ffff0ac00166:4484bcaf:543e967d:154 status: ActionStatus.ABORT_ONLY > 18:34:54,340 INFO [stdout] (http-localhost/127.0.0.1:8080-6) at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:352) 18:34:54,340 INFO [stdout] (http-localhost/127.0.0.1:8080-6) ... 113 more

I was able to determine the original ConstraintViolationException debugging the application but i can't see it in the log. Even i tried to debug and navigate the second exception and it does not contains as a cause the original ConstraintViolationException, clearly is a different one.

Maybe TwoPhaseCoordinator.beforeCompletion is throwing the second exception after the ConstaintViolationException? How can i log this first exception, in order to know which constraints has been violated?

Ricardo Vila
  • 1,626
  • 1
  • 18
  • 34
  • When does the exception occur? On a EntityManager persist/update? Do you want to use validation based on JPA life cycle events? You are saying: "The problem is that in certain service calls (only a few) when a ConstaintViolationException is thrown it is somehow replaced by a chain of exceptions logged like the following:" - does that mean that in some cases constraint violations occur and are handled somewhere else? Or do all constraint violation lead to the satck trace above. Could be related to this - http://stackoverflow.com/questions/14354849/jpa-constraintviolation-vs-rollback/14810664 – Hardy Oct 21 '14 at 09:33
  • Thanks Hardy, it seems that the problem is related to the question you suggested. Apears that HibernatePersistenceProvider is not working as expected. – Ricardo Vila Feb 25 '15 at 14:24

0 Answers0