Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FBXADataSource closes ResultSet in managed transaction [JDBC344] #388

Closed
firebird-automations opened this issue Mar 5, 2014 · 8 comments

Comments

@firebird-automations
Copy link

Submitted by: Sascha Horn (s.horn)

Jira_subtask_outward JDBC346
Relate to JDBC362

We are using a FBXADataSource in a container managed bean in JBoss Application Server.

In this bean we have a method opens a resultset and iterates through the records.
for every record an other statement executes a update.
When we try to access the record (e.g. resultset.getString(1) ) the following exception occurs:

org.firebirdsql.jdbc.FBSQLException: The resultSet is closed
at org.firebirdsql.jdbc.AbstractResultSet.getField(AbstractResultSet.java:661)
at org.firebirdsql.jdbc.AbstractResultSet.getField(AbstractResultSet.java:644)
at org.firebirdsql.jdbc.AbstractResultSet.getString(AbstractResultSet.java:584)
at org.jboss.jca.adapters.jdbc.WrappedResultSet.getString(WrappedResultSet.java:1360)
at de.procar.ecaros2.server.ItemModuleBean.deleteDeletableItemStockLocationAllocations(ItemModuleBean.java:10271)
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.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:58)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:58)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:272)
at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:339)
at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:238)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
at org.jboss.as.ejb3.security.AuthorizationInterceptor.processInvocation(AuthorizationInterceptor.java:122)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:81)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
at org.jboss.as.ejb3.component.interceptors.EjbExceptionTransformingInterceptorFactories$1.processInvocation(EjbExceptionTransformingInterceptorFactories.java:65)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)
at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:329)
at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:70)
at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:203)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
at org.jboss.threads.JBossThread.run(JBossThread.java:122)

I googled a bit...
The solution should be to use setautocommit(false), but this is not
possible in an container managed transaction.

as a workarround i use setDefaultResultSetHoldable(true).
In my opinion the result set may not be closed within an managed
transaction, because commit and rollback should be invoked from the
managed transaction.

Commits: e5462bb 8c91911 FirebirdSQL/fbt-repository@923de83 FirebirdSQL/fbt-repository@a2d19f6

@firebird-automations
Copy link
Author

Commented by: @mrotteveel

I have been able to reproduce this. The problem is that while the FBManagedConnection participates in a distributed transaction, the FBConnection somehow still thinks it is in a local transaction in auto commit. Looking at the code history this problem was introduced by commit https://sourceforge.net/p/firebird/code/56009/ (specifically the changes in AbstractConnection and FBManagedConnection).

That code makes deliberate changes to the initialization of the transaction coordinator for a managed connection, making it initially a local coordinator with autocommit. I will also need to test if this problem was hidden until the introduction of the new datasources in org.firebirdsql.ds, or that the old implementation org.firebirdsql.pool exhibits the same problem (it obtains the XA connection in a slightly different way).

@firebird-automations
Copy link
Author

Commented by: @mrotteveel

Problem could also be caused by https://sourceforge.net/p/firebird/code/56277/

@firebird-automations
Copy link
Author

Commented by: @mrotteveel

By resetting the 'managedEnvironment' property of the FBConnection in the start() and end() methods of the managed connection the transaction coordinator is correctly set and this works ok, however this runs into another problem with a rollback that happens as part of the 'return connection to pool' which I will need to investigate further.

@firebird-automations
Copy link
Author

Commented by: @mrotteveel

Issue has been fixed in Jaybird 2.2.5 (to be released next week).

A more thorough fix will be made in Jaybird 3.0 as there is a situation when using the JCA resource adapter (instead of an XADataSource) with connection sharing enabled where this fix will not work; this however requires a more thorough rework of the code. See JDBC346.

@firebird-automations
Copy link
Author

Modified by: @mrotteveel

Fix Version: Jaybird 2.2.5 [ 10582 ]

Fix Version: Jaybird 3.0 [ 10440 ]

@firebird-automations
Copy link
Author

Modified by: @mrotteveel

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

@firebird-automations
Copy link
Author

Modified by: @mrotteveel

Link: This issue relate to JDBC362 [ JDBC362 ]

@firebird-automations
Copy link
Author

Modified by: @mrotteveel

status: Resolved [ 5 ] => Closed [ 6 ]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment