[JBoss JIRA] (JBTM-2763) problem running with hibernate
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2763?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-2763:
-------------------------------------
Hi David,
Which version of Oracle are you using? I think its because I am closing an underlying connection now but actually it is not meant to close for Oracle (and doesn't in the version I am using) but it matches on Driver name so that might be different in the version you are using.
Many thanks,
Tom
> problem running with hibernate
> ------------------------------
>
> Key: JBTM-2763
> URL: https://issues.jboss.org/browse/JBTM-2763
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JTA
> Affects Versions: 5.3.5.Final
> Environment: Spring 4.3.3.RELEASE
> Hibernate 5.1.2.Final
> Narayana 5.3.5
> Not in an application server - running standalone spring app
> Reporter: davidkarlsen
>
> With the same libraries as above, except narayana 5.3.5 the following config worked just fine:
> {noformat}
> <bean id="abstractEntityManagerFactory" abstract="true" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean" depends-on="cacheManagerFactoryBean">
> <property name="jpaVendorAdapter">
> <bean class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter">
> <property name="generateDdl" value="false" />
> <property name="showSql" value="${hibernate.showSql}" />
> <property name="database">
> <util:constant static-field="org.springframework.orm.jpa.vendor.Database.ORACLE" />
> </property>
> <property name="databasePlatform" value="${hibernate.dialect}" />
> </bean>
> </property>
> <property name="jpaProperties">
> <props>
> <!-- <prop key="hibernate.cache.region.factory_class">net.sf.ehcache.hibernate.EhCacheRegionFactory</prop> -->
> <prop key="hibernate.cache.region.factory_class">org.hibernate.cache.ehcache.SingletonEhCacheRegionFactory</prop>
> <prop key="hibernate.cache.use_query_cache">${hibernate.cache.use_query_cache}</prop>
> <prop key="hibernate.cache.use_second_level_cache">${hibernate.cache.use_second_level_cache}</prop>
> <prop key="hibernate.generate_statistics">${hibernate.generate_statistics}</prop>
> <prop key="hibernate.cache.use_structured_entries">${hibernate.cache.use_structured_entries}</prop>
> <prop key="hibernate.transaction.jta.platform">${hibernate.transaction.jta.platform:org.hibernate.engine.transaction.jta.platform.internal.JBossStandAloneJtaPlatform}</prop>
> <!-- release mode, see:
> https://developer.jboss.org/thread/221140
> http://docs.jboss.org/hibernate/stable/core.old/reference/en/html/transac...
> -->
> <prop key="hibernate.connection.release_mode">${hibernate.connection.release_mode:AFTER_STATEMENT}</prop>
> <prop key="hibernate.jdbc.use_get_generated_keys">${hibernate.jdbc.use_get_generated_keys}</prop>
> <prop key="hibernate.jdbc.fetch_size">${hibernate.jdbc.fetch_size}</prop>
> <prop key="hibernate.jdbc.batch_size">${hibernate.jdbc.batch_size}</prop>
> <prop key="hibernate.show_sql">${hibernate.showSql}</prop>
> <prop key="hibernate.format_sql">${hibernate.format_sql}</prop>
> <prop key="hibernate.use_sql_comments">${hibernate.use_sql_comments}</prop>
> </props>
> </property>
> </bean>
> {noformat}
> If I upgrade Narayana to 5.3.5 I consistently get:
> {noformat}
> java.sql.SQLSyntaxErrorException: ORA-02049: timeout: distributed transaction waiting for lock
> at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:450)
> at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:399)
> at oracle.jdbc.driver.T4C8Oall.processError(T4C8Oall.java:1059)
> at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:522)
> at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:257)
> at oracle.jdbc.driver.T4C8Oall.doOALL(T4C8Oall.java:587)
> at oracle.jdbc.driver.T4CStatement.doOall8(T4CStatement.java:210)
> at oracle.jdbc.driver.T4CStatement.doOall8(T4CStatement.java:30)
> at oracle.jdbc.driver.T4CStatement.executeForRows(T4CStatement.java:931)
> at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1150)
> at oracle.jdbc.driver.OracleStatement.executeInternal(OracleStatement.java:1792)
> at oracle.jdbc.driver.OracleStatement.execute(OracleStatement.java:1745)
> at oracle.jdbc.driver.OracleStatementWrapper.execute(OracleStatementWrapper.java:334)
> at sun.reflect.GeneratedMethodAccessor84.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at net.bull.javamelody.JdbcWrapper.doExecute(JdbcWrapper.java:404)
> at net.bull.javamelody.JdbcWrapper$StatementInvocationHandler.invoke(JdbcWrapper.java:129)
> at net.bull.javamelody.JdbcWrapper$DelegatingInvocationHandler.invoke(JdbcWrapper.java:286)
> at com.sun.proxy.$Proxy143.execute(Unknown Source)
> at org.dbunit.database.statement.SimpleStatement.executeBatch(SimpleStatement.java:69)
> at org.dbunit.operation.DeleteAllOperation.execute(DeleteAllOperation.java:126)
> at org.dbunit.operation.CompositeOperation.execute(CompositeOperation.java:79)
> at com.github.springtestdbunit.DbUnitRunner.setupOrTeardown(DbUnitRunner.java:183)
> at com.github.springtestdbunit.DbUnitRunner.beforeTestMethod(DbUnitRunner.java:75)
> at com.github.springtestdbunit.DbUnitTestExecutionListener.beforeTestMethod(DbUnitTestExecutionListener.java:185)
> at org.springframework.test.context.TestContextManager.beforeTestMethod(TestContextManager.java:269)
> at org.springframework.test.context.junit4.statements.RunBeforeTestMethodCallbacks.evaluate(RunBeforeTestMethodCallbacks.java:74)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.springframework.test.context.junit4.statements.RunAfterTestMethodCallbacks.evaluate(RunAfterTestMethodCallbacks.java:86)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.springframework.test.context.junit4.statements.SpringRepeat.evaluate(SpringRepeat.java:84)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:252)
> at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:94)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61)
> at org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:70)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:191)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.
> {noformat}
> If I leave hibernate.connection.release_mode to default (e.g. not specifying it) or after_transaction I get:
> {noformat}
> WARN com.arjuna.ats.jta - ARJUNA016029: SynchronizationImple.afterCompletion - failed for org.hibernate.resource.transaction.backend.jta.internal.synchronization.RegisteredSynchronization@6811fa19 with exception
> 22:59:01 java.lang.NullPointerException: null
> 22:59:01 at com.arjuna.ats.internal.jdbc.ConnectionImple.getConnection(ConnectionImple.java:864)
> 22:59:01 at com.arjuna.ats.internal.jdbc.ConnectionImple.getWarnings(ConnectionImple.java:476)
> 22:59:01 at sun.reflect.GeneratedMethodAccessor113.invoke(Unknown Source)
> 22:59:01 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 22:59:01 at java.lang.reflect.Method.invoke(Method.java:498)
> 22:59:01 at net.bull.javamelody.JdbcWrapper$ConnectionInvocationHandler.invoke(JdbcWrapper.java:189)
> 22:59:01 at net.bull.javamelody.JdbcWrapper$DelegatingInvocationHandler.invoke(JdbcWrapper.java:286)
> 22:59:01 at com.sun.proxy.$Proxy116.getWarnings(Unknown Source)
> 22:59:01 at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.handleAndClearWarnings(SqlExceptionHelper.java:277)
> 22:59:01 at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.logAndClearWarnings(SqlExceptionHelper.java:256)
> 22:59:01 at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.releaseConnection(LogicalConnectionManagedImpl.java:167)
> 22:59:01 at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.afterTransaction(LogicalConnectionManagedImpl.java:135)
> 22:59:01 at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.afterTransaction(JdbcCoordinatorImpl.java:296)
> 22:59:01 at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.afterTransactionCompletion(JdbcCoordinatorImpl.java:496)
> 22:59:01 at org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorImpl.afterCompletion(JtaTransactionCoordinatorImpl.java:345)
> 22:59:01 at org.hibernate.resource.transaction.backend.jta.internal.synchronization.SynchronizationCallbackCoordinatorNonTrackingImpl.doAfterCompletion(SynchronizationCallbackCoordinatorNonTrackingImpl.java:60)
> 22:59:01 at org.hibernate.resource.transaction.backend.jta.internal.synchronization.SynchronizationCallbackCoordinatorTrackingImpl.afterCompletion(SynchronizationCallbackCoordinatorTrackingImpl.java:72)
> 22:59:01 at org.hibernate.resource.transaction.backend.jta.internal.synchronization.RegisteredSynchronization.afterCompletion(RegisteredSynchronization.java:44)
> 22:59:01 at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.afterCompletion(SynchronizationImple.java:96)
> 22:59:01 at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:542)
> 22:59:01 at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:101)
> 22:59:01 at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
> 22:59:01 at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1216)
> 22:59:01 at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
> 22:59:01 at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:1023)
> 22:59:01 at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:761)
> 22:59:01 at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:730)
> 22:59:01 at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:487)
> 22:59:01 at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:291)
> 22:59:01 at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:96)
> 22:59:01 at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
> 22:59:01 at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:92)
> 22:59:01 at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
> 22:59:01 at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:213)
> 22:59:01 at com.sun.proxy.$Proxy292.create(Unknown Source)
> 22:59:01 at
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 7 months
[JBoss JIRA] (JBTM-2745) Warning messages show with the mdb BlacktieStompAdministrationService and BlacktieAdminServiceXATMI
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2745?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-2745:
-------------------------------------
What issue was this a duplicate of?
> Warning messages show with the mdb BlacktieStompAdministrationService and BlacktieAdminServiceXATMI
> ---------------------------------------------------------------------------------------------------
>
> Key: JBTM-2745
> URL: https://issues.jboss.org/browse/JBTM-2745
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: BlackTie
> Reporter: Amos Feng
> Assignee: Amos Feng
> Priority: Minor
> Fix For: 5.3.5.Final
>
>
> The warning messages
> {code}
> 00:06:48,719 WARN [org.jboss.as.ejb3] (ServerService Thread Pool -- 69) WFLYEJB0485: Transaction type NEVER is unspecified for the onMessage method of the BlacktieStompAdministrationService message-driven bean. It will be handled as NOT_SUPPORTED.
> 00:06:48,721 WARN [org.jboss.as.ejb3] (ServerService Thread Pool -- 67) WFLYEJB0485: Transaction type NEVER is unspecified for the onMessage method of the BlacktieAdminServiceXATMI message-driven bean. It will be handled as NOT_SUPPORTED.
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 7 months
[JBoss JIRA] (JBTM-2735) EIS can't finish all participants of inflow in-doubt transaction after jvm crash
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2735?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-2735:
--------------------------------
Fix Version/s: (was: 5.3.5.Final)
> EIS can't finish all participants of inflow in-doubt transaction after jvm crash
> --------------------------------------------------------------------------------
>
> Key: JBTM-2735
> URL: https://issues.jboss.org/browse/JBTM-2735
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JTA, JTS
> Affects Versions: 5.3.3.Final
> Reporter: Ondra Chaloupka
> Assignee: Tom Jenkinson
> Priority: Critical
>
> When EIS RAR manages inflow transaction through {{XATerminator}} calls and jvm of TM is crashed at the start of commit phase then EIS can't recover all transaction participants.
> Expected flow of the case would be
> # enlist two participants of inflow transaction - that means TM manages subordinate transaction and accepts orders from EIS RAR
> # TM receives commit order by EIS RAR call {{XATerminator.commit}}
> # TM prepares both participants
> # end phase prepares, start phase commits
> # JVM crashes
> # app server is restarted again
> # EIS system repeats commit call as subordinate txn was not finished
> # TM calls commit on both participants to finish the transaction
> This scenario has two troubles in current implementation
> If app server is restarted (after jvm crash happened) and EIS calls commit right after the start there is thrown {{XAER_RMFAIL}} when XATerminator.commit is called.
> For the commit have got a real effect on in-doubt transaciton there needs to be called recovery first. From that point in time the in-doubt inflow transaction is "available" for EIS RAR XATerminator.commit call. But there is another issue. Transaction was stopped with two participants prepared. But after commit is called from XATerminator only one XAResource is committed. The other one is left and forgotten. As the transaction itself is resolved as finished (thus removed from log store) there is no way to get to the remaining in-doubt participant - at least with help of jboss cli tooling.
> (_The reason could be that both XA resources shared the xid, as discussed in other place, TM does not rights to change xid and it needs to reuse existing one provided by EIS to all the work_)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 7 months
[JBoss JIRA] (JBTM-2735) EIS can't finish all participants of inflow in-doubt transaction after jvm crash
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2735?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson closed JBTM-2735.
-------------------------------
Resolution: Rejected
> EIS can't finish all participants of inflow in-doubt transaction after jvm crash
> --------------------------------------------------------------------------------
>
> Key: JBTM-2735
> URL: https://issues.jboss.org/browse/JBTM-2735
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JTA, JTS
> Affects Versions: 5.3.3.Final
> Reporter: Ondra Chaloupka
> Assignee: Tom Jenkinson
> Priority: Critical
>
> When EIS RAR manages inflow transaction through {{XATerminator}} calls and jvm of TM is crashed at the start of commit phase then EIS can't recover all transaction participants.
> Expected flow of the case would be
> # enlist two participants of inflow transaction - that means TM manages subordinate transaction and accepts orders from EIS RAR
> # TM receives commit order by EIS RAR call {{XATerminator.commit}}
> # TM prepares both participants
> # end phase prepares, start phase commits
> # JVM crashes
> # app server is restarted again
> # EIS system repeats commit call as subordinate txn was not finished
> # TM calls commit on both participants to finish the transaction
> This scenario has two troubles in current implementation
> If app server is restarted (after jvm crash happened) and EIS calls commit right after the start there is thrown {{XAER_RMFAIL}} when XATerminator.commit is called.
> For the commit have got a real effect on in-doubt transaciton there needs to be called recovery first. From that point in time the in-doubt inflow transaction is "available" for EIS RAR XATerminator.commit call. But there is another issue. Transaction was stopped with two participants prepared. But after commit is called from XATerminator only one XAResource is committed. The other one is left and forgotten. As the transaction itself is resolved as finished (thus removed from log store) there is no way to get to the remaining in-doubt participant - at least with help of jboss cli tooling.
> (_The reason could be that both XA resources shared the xid, as discussed in other place, TM does not rights to change xid and it needs to reuse existing one provided by EIS to all the work_)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 7 months
[JBoss JIRA] (JBTM-2735) EIS can't finish all participants of inflow in-doubt transaction after jvm crash
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2735?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson reopened JBTM-2735:
---------------------------------
> EIS can't finish all participants of inflow in-doubt transaction after jvm crash
> --------------------------------------------------------------------------------
>
> Key: JBTM-2735
> URL: https://issues.jboss.org/browse/JBTM-2735
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JTA, JTS
> Affects Versions: 5.3.3.Final
> Reporter: Ondra Chaloupka
> Assignee: Tom Jenkinson
> Priority: Critical
> Fix For: 5.3.5.Final
>
>
> When EIS RAR manages inflow transaction through {{XATerminator}} calls and jvm of TM is crashed at the start of commit phase then EIS can't recover all transaction participants.
> Expected flow of the case would be
> # enlist two participants of inflow transaction - that means TM manages subordinate transaction and accepts orders from EIS RAR
> # TM receives commit order by EIS RAR call {{XATerminator.commit}}
> # TM prepares both participants
> # end phase prepares, start phase commits
> # JVM crashes
> # app server is restarted again
> # EIS system repeats commit call as subordinate txn was not finished
> # TM calls commit on both participants to finish the transaction
> This scenario has two troubles in current implementation
> If app server is restarted (after jvm crash happened) and EIS calls commit right after the start there is thrown {{XAER_RMFAIL}} when XATerminator.commit is called.
> For the commit have got a real effect on in-doubt transaciton there needs to be called recovery first. From that point in time the in-doubt inflow transaction is "available" for EIS RAR XATerminator.commit call. But there is another issue. Transaction was stopped with two participants prepared. But after commit is called from XATerminator only one XAResource is committed. The other one is left and forgotten. As the transaction itself is resolved as finished (thus removed from log store) there is no way to get to the remaining in-doubt participant - at least with help of jboss cli tooling.
> (_The reason could be that both XA resources shared the xid, as discussed in other place, TM does not rights to change xid and it needs to reuse existing one provided by EIS to all the work_)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 7 months
[JBoss JIRA] (JBTM-2728) Add a forget operation to the tooling
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2728?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson closed JBTM-2728.
-------------------------------
Resolution: Done
> Add a forget operation to the tooling
> -------------------------------------
>
> Key: JBTM-2728
> URL: https://issues.jboss.org/browse/JBTM-2728
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Components: Tooling
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Fix For: 5.3.5.Final
>
>
> The tooling provides two features for dealing with heuristic participants:
> * a recover command that will move it back into the prepared state if the admin thinks a second prepare attempt is likely to succeed;
> * a delete operation if the admin thinks it safe to do so;
>
> In the case of XA resources we also need a forget operation which will trigger the resource adaptor to clean up its end instead of relying on the admin to use tooling provided by the RA to clean up.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 7 months