[JBoss JIRA] (JBTM-2763) problem running with hibernate
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2763?page=com.atlassian.jira.plugin.... ]
Issue was automatically transitioned when Tom Jenkinson created pull request #1089 in GitHub
--------------------------------------------------------------------------------------------
Status: Pull Request Sent (was: Open)
> 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
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (JBTM-2787) TestGroup_txcore_recovery::Recovery_Crash_StateManager_Test004 fails with DB2
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2787?page=com.atlassian.jira.plugin.... ]
Issue was automatically transitioned when Tom Jenkinson created pull request #1088 in GitHub
--------------------------------------------------------------------------------------------
Status: Pull Request Sent (was: Open)
> TestGroup_txcore_recovery::Recovery_Crash_StateManager_Test004 fails with DB2
> -----------------------------------------------------------------------------
>
> Key: JBTM-2787
> URL: https://issues.jboss.org/browse/JBTM-2787
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: Testing
> Reporter: Tom Jenkinson
> Assignee: Tom Jenkinson
> Fix For: 5.next
>
>
> When DB2 tests are running (this is a very slow configuration for CI) the recovery manager process appears to be interfering with the setup of the test.
> Set up of test:
> 2016-11-06 16:04:03,172 out: 2016-11-06 16:04:03,172 [main] WARN com.arjuna.ats.arjuna - ARJUNA012382: Action id 0:ffffac11000a:c397:581f5466:4 could not be transitioned to committed
> Recovery manager process:
> 2016-11-06 16:04:24,188 out: 2016-11-06 16:04:24,188 [Periodic Recovery] WARN com.arjuna.ats.arjuna - ARJUNA012382: Action id 0:ffffac11000a:c397:581f5466:1 could not be transitioned to committed
> 2016-11-06 16:04:24,225 out: 2016-11-06 16:04:24,225 [Periodic Recovery] WARN com.arjuna.ats.arjuna - ARJUNA012016: PersistenceRecord::topLevelCommit - commit_state call failed for 0:ffffac11000a:c397:581f5466:1
> 2016-11-06 16:04:24,225 out: 2016-11-06 16:04:24,225 [Periodic Recovery] WARN com.arjuna.ats.arjuna - ARJUNA012022: PersistenceRecord::topLevelCommit - commit_state error
> 2016-11-06 16:04:25,504 out: 2016-11-06 16:04:25,504 [Periodic Recovery] WARN com.arjuna.ats.arjuna - ARJUNA012382: Action id 0:ffffac11000a:c397:581f5466:3 could not be transitioned to committed
> 2016-11-06 16:04:25,549 out: 2016-11-06 16:04:25,549 [Periodic Recovery] WARN com.arjuna.ats.arjuna - ARJUNA012016: PersistenceRecord::topLevelCommit - commit_state call failed for 0:ffffac11000a:c397:581f5466:3
> 2016-11-06 16:04:25,549 out: 2016-11-06 16:04:25,549 [Periodic Recovery] WARN com.arjuna.ats.arjuna - ARJUNA012022: PersistenceRecord::topLevelCommit - commit_state error
> 2016-11-06 16:04:37,523 out: 2016-11-06 16:04:37,523 [Periodic Recovery] WARN com.arjuna.ats.arjuna - ARJUNA012382: Action id 0:ffffac11000a:c397:581f5466:4 could not be transitioned to committed
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (JBTM-2787) TestGroup_txcore_recovery::Recovery_Crash_StateManager_Test004 fails with DB2
by Tom Jenkinson (JIRA)
Tom Jenkinson created JBTM-2787:
-----------------------------------
Summary: TestGroup_txcore_recovery::Recovery_Crash_StateManager_Test004 fails with DB2
Key: JBTM-2787
URL: https://issues.jboss.org/browse/JBTM-2787
Project: JBoss Transaction Manager
Issue Type: Bug
Components: Testing
Reporter: Tom Jenkinson
Assignee: Tom Jenkinson
Fix For: 5.next
When DB2 tests are running (this is a very slow configuration for CI) the recovery manager process appears to be interfering with the setup of the test.
Set up of test:
2016-11-06 16:04:03,172 out: 2016-11-06 16:04:03,172 [main] WARN com.arjuna.ats.arjuna - ARJUNA012382: Action id 0:ffffac11000a:c397:581f5466:4 could not be transitioned to committed
Recovery manager process:
2016-11-06 16:04:24,188 out: 2016-11-06 16:04:24,188 [Periodic Recovery] WARN com.arjuna.ats.arjuna - ARJUNA012382: Action id 0:ffffac11000a:c397:581f5466:1 could not be transitioned to committed
2016-11-06 16:04:24,225 out: 2016-11-06 16:04:24,225 [Periodic Recovery] WARN com.arjuna.ats.arjuna - ARJUNA012016: PersistenceRecord::topLevelCommit - commit_state call failed for 0:ffffac11000a:c397:581f5466:1
2016-11-06 16:04:24,225 out: 2016-11-06 16:04:24,225 [Periodic Recovery] WARN com.arjuna.ats.arjuna - ARJUNA012022: PersistenceRecord::topLevelCommit - commit_state error
2016-11-06 16:04:25,504 out: 2016-11-06 16:04:25,504 [Periodic Recovery] WARN com.arjuna.ats.arjuna - ARJUNA012382: Action id 0:ffffac11000a:c397:581f5466:3 could not be transitioned to committed
2016-11-06 16:04:25,549 out: 2016-11-06 16:04:25,549 [Periodic Recovery] WARN com.arjuna.ats.arjuna - ARJUNA012016: PersistenceRecord::topLevelCommit - commit_state call failed for 0:ffffac11000a:c397:581f5466:3
2016-11-06 16:04:25,549 out: 2016-11-06 16:04:25,549 [Periodic Recovery] WARN com.arjuna.ats.arjuna - ARJUNA012022: PersistenceRecord::topLevelCommit - commit_state error
2016-11-06 16:04:37,523 out: 2016-11-06 16:04:37,523 [Periodic Recovery] WARN com.arjuna.ats.arjuna - ARJUNA012382: Action id 0:ffffac11000a:c397:581f5466:4 could not be transitioned to committed
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (JBTM-2785) Provide a tooling operation to suspend/resume the recovery manager
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-2785?page=com.atlassian.jira.plugin.... ]
Michael Musgrove commented on JBTM-2785:
----------------------------------------
Note that I have not raised a corresponding documentation issue because we only support transaction log management (in WildFly/EAP) in the same process that the recovery manager is running so we can call the (MBean) suspend/resume operations directly from the tooling so there is nothing that user needs to do (and therefore no documentation requirement).
> Provide a tooling operation to suspend/resume the recovery manager
> ------------------------------------------------------------------
>
> Key: JBTM-2785
> URL: https://issues.jboss.org/browse/JBTM-2785
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Components: Tooling
> Affects Versions: 5.3.5.Final
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
>
> Some tooling operations update the state of transaction log records and these updates could interfere with what the recovery manager is doing. Tooling updates should pause the recovery manager prior to performing such updates. Since tooling and recovery can run in different JVMs we need an MBean operation to suspend/resume the recovery manager to protect against this scenario.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (JBTM-2785) Provide a tooling operation to suspend/resume the recovery manager
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-2785?page=com.atlassian.jira.plugin.... ]
Michael Musgrove updated JBTM-2785:
-----------------------------------
Summary: Provide a tooling operation to suspend/resume the recovery manager (was: Provide a tooling operation to suspend the recovery manager)
> Provide a tooling operation to suspend/resume the recovery manager
> ------------------------------------------------------------------
>
> Key: JBTM-2785
> URL: https://issues.jboss.org/browse/JBTM-2785
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Components: Tooling
> Affects Versions: 5.3.5.Final
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
>
> Some tooling operations update the state of transaction log records and these updates could interfere with what the recovery manager is doing. Tooling updates should pause the recovery manager prior to performing such updates. Since tooling and recovery can run in different JVMs we need an MBean operation to suspend/resume the recovery manager to protect against this scenario.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (JBTM-2785) Provide a tooling operation to suspend the recovery manager
by Michael Musgrove (JIRA)
Michael Musgrove created JBTM-2785:
--------------------------------------
Summary: Provide a tooling operation to suspend the recovery manager
Key: JBTM-2785
URL: https://issues.jboss.org/browse/JBTM-2785
Project: JBoss Transaction Manager
Issue Type: Feature Request
Components: Tooling
Affects Versions: 5.3.5.Final
Reporter: Michael Musgrove
Assignee: Michael Musgrove
Some tooling operations update the state of transaction log records and these updates could interfere with what the recovery manager is doing. Tooling updates should pause the recovery manager prior to performing such updates. Since tooling and recovery can run in different JVMs we need an MBean operation to suspend/resume the recovery manager to protect against this scenario.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (JBTM-2767) Allow JTS JCA imported transactions to have clearHeuristic called on their participants
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2767?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-2767:
--------------------------------
Issue Type: Bug (was: Enhancement)
> Allow JTS JCA imported transactions to have clearHeuristic called on their participants
> ---------------------------------------------------------------------------------------
>
> Key: JBTM-2767
> URL: https://issues.jboss.org/browse/JBTM-2767
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JCA, JTS
> Affects Versions: 5.3.5.Final
> Reporter: Ondra Chaloupka
> Assignee: Tom Jenkinson
> Priority: Minor
> Fix For: 5.next
>
>
> If an XAResource throws a heuristic we can't forget it but we do clean up some transactional state meaning it will need reloading from disk (after the heuristic is cleared) before it can be meaningfully used again. In the state where it can't be meaningfully used we need to provide something to the caller.
> [1]
> {code}
> 2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) java.lang.NullPointerException2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1)
> at com.arjuna.ats.internal.jta.transaction.jts.subordinate.jca.SubordinateAtomicTransaction.getXid(SubordinateAtomicTransaction.java:80)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1)
> at com.arjuna.ats.internal.jta.transaction.jts.subordinate.jca.TransactionImple.baseXid(TransactionImple.java:126)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) at com.arjuna.ats.internal.jta.transaction.jts.jca.TransactionImporterImple.getImportedTransaction(TransactionImporterImple.java:135)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1)
> at com.arjuna.ats.internal.jta.transaction.jts.jca.XATerminatorImple.commit(XATerminatorImple.java:83)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1)
> at org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit.run(Unknown Source)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1)
> at org.jboss.jca.core.workmanager.WorkWrapper.run(WorkWrapper.java:223)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1)
> at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1)
> at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:808)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1)
> at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1)
> at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:828)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1)
> at java.lang.Thread.run(Thread.java:745)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> 2016-10-05 16:19:23,538 ERROR [org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit] (default-threads - 1) Unspecified sever exception: java.lang.NullPointerException at com.arjuna.ats.internal.jta.transaction.jts.subordinate.jca.TransactionImple.recover(TransactionImple.java:135)
> at com.arjuna.ats.internal.jta.transaction.jts.jca.TransactionImporterImple.getImportedTransaction(TransactionImporterImple.java:141)
> at com.arjuna.ats.internal.jta.transaction.jts.jca.XATerminatorImple.commit(XATerminatorImple.java:83) at org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit.run(Unknown Source) at org.jboss.jca.core.workmanager.WorkWrapper.run(WorkWrapper.java:223)
> at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33) at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:808)
> at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45)
> at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:828)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (JBTM-2767) Updated to allow JTS JCA imported transactions to have clearHeuristic called on their participants
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2767?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-2767:
--------------------------------
Component/s: JCA
> Updated to allow JTS JCA imported transactions to have clearHeuristic called on their participants
> --------------------------------------------------------------------------------------------------
>
> Key: JBTM-2767
> URL: https://issues.jboss.org/browse/JBTM-2767
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Components: JCA, JTS
> Affects Versions: 5.3.5.Final
> Reporter: Ondra Chaloupka
> Assignee: Tom Jenkinson
> Priority: Minor
> Fix For: 5.next
>
>
> If an XAResource throws a heuristic we can't forget it but we do clean up some transactional state meaning it will need reloading from disk (after the heuristic is cleared) before it can be meaningfully used again. In the state where it can't be meaningfully used we need to provide something to the caller.
> [1]
> {code}
> 2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) java.lang.NullPointerException2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1)
> at com.arjuna.ats.internal.jta.transaction.jts.subordinate.jca.SubordinateAtomicTransaction.getXid(SubordinateAtomicTransaction.java:80)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1)
> at com.arjuna.ats.internal.jta.transaction.jts.subordinate.jca.TransactionImple.baseXid(TransactionImple.java:126)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) at com.arjuna.ats.internal.jta.transaction.jts.jca.TransactionImporterImple.getImportedTransaction(TransactionImporterImple.java:135)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1)
> at com.arjuna.ats.internal.jta.transaction.jts.jca.XATerminatorImple.commit(XATerminatorImple.java:83)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1)
> at org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit.run(Unknown Source)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1)
> at org.jboss.jca.core.workmanager.WorkWrapper.run(WorkWrapper.java:223)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1)
> at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1)
> at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:808)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1)
> at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1)
> at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:828)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1)
> at java.lang.Thread.run(Thread.java:745)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> 2016-10-05 16:19:23,538 ERROR [org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit] (default-threads - 1) Unspecified sever exception: java.lang.NullPointerException at com.arjuna.ats.internal.jta.transaction.jts.subordinate.jca.TransactionImple.recover(TransactionImple.java:135)
> at com.arjuna.ats.internal.jta.transaction.jts.jca.TransactionImporterImple.getImportedTransaction(TransactionImporterImple.java:141)
> at com.arjuna.ats.internal.jta.transaction.jts.jca.XATerminatorImple.commit(XATerminatorImple.java:83) at org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit.run(Unknown Source) at org.jboss.jca.core.workmanager.WorkWrapper.run(WorkWrapper.java:223)
> at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33) at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:808)
> at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45)
> at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:828)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months