September 2016 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-2763) problem running with hibernate

by davidkarlsen (JIRA)

davidkarlsen created JBTM-2763: ---------------------------------- Summary: 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">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>  <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)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2498) Incomplete BlackTie quickstart documentation

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2498?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2498: -------------------------------- Fix Version/s: 5.3.5.Final (was: 5.next) > Incomplete BlackTie quickstart documentation > -------------------------------------------- > > Key: JBTM-2498 > URL: https://issues.jboss.org/browse/JBTM-2498 > Project: JBoss Transaction Manager > Issue Type: Task > Components: BlackTie, Demonstrator, Documentation > Affects Versions: 5.2.2 > Reporter: Michael Musgrove > Assignee: Amos Feng > Priority: Minor > Fix For: 5.3.5.Final > > > The BlackTie README.md quickstart files are out of date with respect to running against the latest wildfly. > Ideally, the quickstarts should be standalone (and automatable - run.sh nearly works but not quite) so we need better instructions on how to configure, start and deploy to wildfly. > My ideal quickstart is one from which I can cut lines and paste into a terminal in order to get it working. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2498) Incomplete BlackTie quickstart documentation

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2498?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2498. ------------------------------- Resolution: Done > Incomplete BlackTie quickstart documentation > -------------------------------------------- > > Key: JBTM-2498 > URL: https://issues.jboss.org/browse/JBTM-2498 > Project: JBoss Transaction Manager > Issue Type: Task > Components: BlackTie, Demonstrator, Documentation > Affects Versions: 5.2.2 > Reporter: Michael Musgrove > Assignee: Amos Feng > Priority: Minor > Fix For: 5.3.5.Final > > > The BlackTie README.md quickstart files are out of date with respect to running against the latest wildfly. > Ideally, the quickstarts should be standalone (and automatable - run.sh nearly works but not quite) so we need better instructions on how to configure, start and deploy to wildfly. > My ideal quickstart is one from which I can cut lines and paste into a terminal in order to get it working. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2755) Allow btadmin to load servers from 127.0.0.1

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2755?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2755: -------------------------------- Fix Version/s: 5.3.5.Final (was: 5.next) > Allow btadmin to load servers from 127.0.0.1 > -------------------------------------------- > > Key: JBTM-2755 > URL: https://issues.jboss.org/browse/JBTM-2755 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: BlackTie > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.3.5.Final > > > This means that when we add new nodes we don't have to add to the test each time -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2755) Allow btadmin to load servers from 127.0.0.1

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2755?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2755. ------------------------------- Resolution: Done > Allow btadmin to load servers from 127.0.0.1 > -------------------------------------------- > > Key: JBTM-2755 > URL: https://issues.jboss.org/browse/JBTM-2755 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: BlackTie > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.3.5.Final > > > This means that when we add new nodes we don't have to add to the test each time -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2749) Add an SPI method to lookup imported transactions by Xid

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2749?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2749: -------------------------------- Fix Version/s: 5.3.5.Final (was: 5.next) > Add an SPI method to lookup imported transactions by Xid > -------------------------------------------------------- > > Key: JBTM-2749 > URL: https://issues.jboss.org/browse/JBTM-2749 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JCA, SPI > Affects Versions: 5.3.4.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Critical > Fix For: 5.3.5.Final > > > When EJB remoting sees an incoming transaction it needs to determine whether it is one that the TM already knows about and should just resume it or if it needs to start a new subordinate transaction for it on this node. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2749) Add an SPI method to lookup imported transactions by Xid

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2749?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2749. ------------------------------- Resolution: Done > Add an SPI method to lookup imported transactions by Xid > -------------------------------------------------------- > > Key: JBTM-2749 > URL: https://issues.jboss.org/browse/JBTM-2749 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JCA, SPI > Affects Versions: 5.3.4.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Critical > Fix For: 5.3.5.Final > > > When EJB remoting sees an incoming transaction it needs to determine whether it is one that the TM already knows about and should just resume it or if it needs to start a new subordinate transaction for it on this node. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2752) Database connection on POSTGRE required max_prepared_statement

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2752?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2752: -------------------------------- Fix Version/s: 5.3.5.Final (was: 5.next) > Database connection on POSTGRE required max_prepared_statement > -------------------------------------------------------------- > > Key: JBTM-2752 > URL: https://issues.jboss.org/browse/JBTM-2752 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.3.5.Final > > > max_prepared_statement is required on the file (postgre.conf) to connect on pgsql base. > If this option wasn't activate, the method end is called twice on PGXAConnection > Please find below original discussion : > https://developer.jboss.org/message/958507#958507 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2752) Database connection on POSTGRE required max_prepared_statement

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2752?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2752. ------------------------------- > Database connection on POSTGRE required max_prepared_statement > -------------------------------------------------------------- > > Key: JBTM-2752 > URL: https://issues.jboss.org/browse/JBTM-2752 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.3.5.Final > > > max_prepared_statement is required on the file (postgre.conf) to connect on pgsql base. > If this option wasn't activate, the method end is called twice on PGXAConnection > Please find below original discussion : > https://developer.jboss.org/message/958507#958507 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

[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. ------------------------------- > Add a forget operation to the tooling > ------------------------------------- > > Key: JBTM-2728 > URL: https://issues.jboss.org/browse/JBTM-2728 > Project: JBoss Transaction Manager > Issue Type: Feature Request > 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)

8 years, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues September 2016