2 Replies Latest reply on Aug 21, 2009 11:16 AM by deepak aggarwal

    jboss 4.2.3 and WrappedConnection.checkTransactionStatus pro

    deepak aggarwal Newbie

      Hi,
      When using jboss 4.2.3 with our app, we got an error of this sort (from memory):

      Cannot Execute query.....Transaction status marked rollback
      Caused by: jboss.util.NestedSQLException
      at ...WrappedConnection.checkTransactionStatus
      


      Scenario when the above error happens:

      a) User submits request from a web page
      b) A jta transaction is started in a filter
      c) From UI layer, transaction is propagated to service layer with "Propation Required" setting.
      d) Service layer throws an exception (validation) and transaction is marked for rollback. Note that it is marked for rollback and not rolledback
      e) The ui layer now prepares the view which requires some db queries to be executed. As soon as the first query is tried to be executed, the above exception is thrown.

      I tried the above same steps with jboss 4.2.1 and it works fine. On further probing, found that in jboss 4.2.3, there was a change made as part of:
      https://jira.jboss.org/jira/browse/JBAS-5080
      https://jira.jboss.org/jira/browse/JBAS-5083

      From jira links above, intention seems to be to prevent update sqls from getting exectuted when transaction is marked for rollback. But looks like the code that was added does not discriminate between read-only and update sqls and prevents even a prepared statement from getting created - WrappedConnection.checkTransactionStatus throws an exception "cannot execute query" transaction marked for rollback.

      I believe that jca should discriminate between read only and update queries and should *allow* read only queries to go through when transaction is marked for rollback. These would allow the views to get generated in the same transaction. Ours is a 2-tier system (ui + service layer execute in the same jvm) and we are using Hibernate's recommended OpenSessionInViewPattern with one hib session+ one transaction per request. Else, we'll have to refactor our code to have one hib session + 2 transactions (one for service layer and the other for the view).

      Anyone has any thoughts about this?