aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Grzegorz Grzybek (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ARIES-1279) Transaction does not work on error SQLException
Date Thu, 12 Feb 2015 12:18:13 GMT

    [ 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<Connection, ConnectionHandle> 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)

Mime
View raw message