Return-Path: X-Original-To: apmail-aries-dev-archive@www.apache.org Delivered-To: apmail-aries-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 68D7010A4E for ; Thu, 12 Feb 2015 12:18:13 +0000 (UTC) Received: (qmail 45031 invoked by uid 500); 12 Feb 2015 12:18:13 -0000 Delivered-To: apmail-aries-dev-archive@aries.apache.org Received: (qmail 44984 invoked by uid 500); 12 Feb 2015 12:18:13 -0000 Mailing-List: contact dev-help@aries.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@aries.apache.org Delivered-To: mailing list dev@aries.apache.org Received: (qmail 44971 invoked by uid 99); 12 Feb 2015 12:18:13 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 12 Feb 2015 12:18:13 +0000 Date: Thu, 12 Feb 2015 12:18:13 +0000 (UTC) From: "Grzegorz Grzybek (JIRA)" To: dev@aries.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (ARIES-1279) Transaction does not work on error SQLException MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/ARIES-1279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14318093#comment-14318093 ] Grzegorz Grzybek commented on ARIES-1279: ----------------------------------------- Hi [~alexey-s], I've just checked your scenario The difference between simple {{throw new Exception("send error"); // it's test work OK}} and implicit {{SQLException}} thrown from {{connection.prepareStatement("SELECT ID FROM MYTABLE")}} is that the connection you're operating on is really an instance of {{org.tranql.connector.jdbc.ConnectionHandle}}. So {{connectionError(e)}} is invoked in the following code of {{org.tranql.connector.jdbc.ConnectionHandle#prepareStatement(java.lang.String)}}: {code:java} public PreparedStatement prepareStatement(String sql) throws SQLException { ManagedConnectionHandle mc = getManagedConnection(); try { return wrapPreparedStatement(mc.getPhysicalConnection().prepareStatement(sql)); } catch (SQLException e) { connectionError(e); throw e; } } {code} So you can be sure that actual physical Derby connection is closed here: {code:java} protected void closePhysicalConnection() throws ResourceException { Connection c = (Connection) physicalConnection; try { // actual closing of physical connection c.close(); } catch (SQLException e) { throw new ResourceAdapterInternalException("Error attempting to destroy managed connection", e); } } {code} The stack trace is: {noformat} at org.tranql.connector.jdbc.ManagedJDBCConnection.closePhysicalConnection(ManagedJDBCConnection.java:143) at org.tranql.connector.AbstractManagedConnection.destroy(AbstractManagedConnection.java:72) at org.apache.geronimo.connector.outbound.MCFConnectionInterceptor.returnConnection(MCFConnectionInterceptor.java:67) at org.apache.geronimo.connector.outbound.LocalXAResourceInsertionInterceptor.returnConnection(LocalXAResourceInsertionInterceptor.java:50) at org.apache.geronimo.connector.outbound.AbstractSinglePoolConnectionInterceptor.internalReturn(AbstractSinglePoolConnectionInterceptor.java:185) at org.apache.geronimo.connector.outbound.AbstractSinglePoolConnectionInterceptor.returnConnection(AbstractSinglePoolConnectionInterceptor.java:129) at org.apache.geronimo.connector.outbound.TransactionEnlistingInterceptor.returnConnection(TransactionEnlistingInterceptor.java:113) at org.apache.geronimo.connector.outbound.TransactionCachingInterceptor.returnConnection(TransactionCachingInterceptor.java:119) at org.apache.geronimo.connector.outbound.ConnectionHandleInterceptor.returnConnection(ConnectionHandleInterceptor.java:71) at org.apache.geronimo.connector.outbound.TCCLInterceptor.returnConnection(TCCLInterceptor.java:50) at org.apache.geronimo.connector.outbound.ConnectionTrackingInterceptor.returnConnection(ConnectionTrackingInterceptor.java:91) at org.apache.geronimo.connector.outbound.GeronimoConnectionEventListener.connectionErrorOccurred(GeronimoConnectionEventListener.java:95) at org.tranql.connector.AbstractManagedConnection.unfilteredConnectionError(AbstractManagedConnection.java:126) at org.tranql.connector.AbstractManagedConnection.connectionError(AbstractManagedConnection.java:115) at org.tranql.connector.jdbc.ConnectionHandle.connectionError(ConnectionHandle.java:112) at org.tranql.connector.jdbc.ConnectionHandle.prepareStatement(ConnectionHandle.java:243) at test.TestRollback.internalProcess(TestRollback.java:119) at test.TestRollback.internalProcess(TestRollback.java:100) at test.TestRollback.test(TestRollback.java:76) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) at org.junit.runners.ParentRunner.run(ParentRunner.java:309) at org.junit.runner.JUnitCore.run(JUnitCore.java:160) at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:74) at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:212) at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:68) {noformat} In your example, this code is not necessary: {code:java} if (manager.getRollbackOnly()) { LOGGER.debug("transaction rollback"); manager.rollback(); {code} because rollback was already called here: {code:java} public void connectionError(Exception e) { if (exceptionSorter.isExceptionFatal(e)) { if (exceptionSorter.rollbackOnFatalException()) { attemptRollback(); } unfilteredConnectionError(e); } } {code} So you can configure this behavior by setting other _exception sorter_ using this method: {{org.apache.aries.transaction.jdbc.RecoverableDataSource#setExceptionSorter()}}. regards Grzegorz Grzybek > Transaction does not work on error SQLException > ----------------------------------------------- > > Key: ARIES-1279 > URL: https://issues.apache.org/jira/browse/ARIES-1279 > Project: Aries > Issue Type: Bug > Components: Transaction > Environment: org.apache.aries.transaction.jdbc:2.1.0 > org.apache.aries.transaction.manager:1.1.0 > org.apache.geronimo.components.geronimo-connector:3.1.1 > Reporter: Aleksey Sushko > Priority: Critical > Attachments: transaction-itest.zip > > > Tests show incorrect operation of the database. > Stack error bit different. But the result is the same. > If the error on the level of queries to the database, the test falls. > If the error in the logic of business process, the test passes. > {code}throw new Exception("send error"); // it's test work OK{code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)