On executing readonly query, WrappedConnection.checkTransactionStatus throws exception when transaction is marked for roll back

Unable to execute read-only query when UserTransaction set to setRollbackOnly() . This does not appear to be a problem associated with transactions but JCA. A change of status from active to rollbackOnly within the same transaction is not in itself sufficient grounds to require the rejection of the second sql statement, since it does not endanger the ACID guarantees. Executing further operations on a tx that is going to rollback is arguably a waste of effort, but won't actually result in data inconsistency even if some of them are updates - they will all be reverted when the tx rolls back.

Test code :

protected void processRequest(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
response.setContentType("text/html;charset=UTF-8");
PrintWriter out = response.getWriter();
Connection connection = null;
try

{ InitialContext initialContext = new InitialContext(); UserTransaction ut = (UserTransaction) initialContext.lookup("java:comp/UserTransaction"); ut.begin(); DataSource ds = (DataSource) initialContext.lookup("java:/DefaultDS"); connection = ds.getConnection(); connection.prepareCall("select * from JBM_USER").execute(); ut.setRollbackOnly(); connection.prepareCall("select * from JBM_USER").execute(); ut.rollback(); }

catch (SQLException ex)

{ ex.printStackTrace(); } catch (NotSupportedException ex) { ex.printStackTrace(); }

catch (SystemException ex)

{ ex.printStackTrace(); }

catch(NamingException e)

{ e.printStackTrace(); }

finally

{ if(out != null) out.close(); closeConnection(connection); }

}