[
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)
