June 2011 - jbossts-issues - Jboss List Archives

[JBoss JIRA] Created: (JBTM-451) Check XTS default timeout

by Mark Little (JIRA)

Check XTS default timeout ------------------------- Key: JBTM-451 URL: https://jira.jboss.org/jira/browse/JBTM-451 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: WS-T Implementation Affects Versions: 4.4.0.GA Reporter: Mark Little Assignee: Mark Little Fix For: 4.6 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

6
13
0 / 0

[JBoss JIRA] Created: (JBTM-751) Dirty transaction remains if rollback failed

by Teofilis Martisius (JIRA)

Dirty transaction remains if rollback failed -------------------------------------------- Key: JBTM-751 URL: https://jira.jboss.org/browse/JBTM-751 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: JTA Affects Versions: 4.6.1 Environment: Jboss 5.1.0GA Reporter: Teofilis Martisius Priority: Minor Hi, I noticed that in some cases when transaction rollback fails, remaining dirty transaction is left associated with the thread when it gets returned to thread pool. Same thread gets used again producing errors. I have attached a patch I have used successfully for a while in my deployment. This patch is applicable to v4.6.1GA, but I think other versions are also affected. This issue gets triggered by exception like this one: ERROR [org.hibernate.event.def.AbstractFlushingEventListener] (WorkManager(2)-17) Could not synchronize database state with session org.hibernate.exception.LockAcquisitionException: could not update: [org.jbpm.graph.exe.Token#15022] at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:105) at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:66) at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2453) at org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:2335) at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2635) at org.hibernate.action.EntityUpdateAction.execute(EntityUpdateAction.java:115) at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:279) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:263) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:168) at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:321) at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:50) at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1027) at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:365) at org.hibernate.transaction.CacheSynchronization.beforeCompletion(CacheSynchronization.java:88) at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:101) at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:269) at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:89) at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:177) at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1475) at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:137) at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75) at org.jboss.resource.adapter.jms.inflow.JmsServerSession$XATransactionDemarcationStrategy.end(JmsServerSession.java:657) at org.jboss.resource.adapter.jms.inflow.JmsServerSession.run(JmsServerSession.java:243) at org.jboss.resource.work.WorkWrapper.execute(WorkWrapper.java:205) at org.jboss.util.threadpool.BasicTaskWrapper.run(BasicTaskWrapper.java:260) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException: Deadlock found when trying to get lock; try restarting transaction at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at com.mysql.jdbc.Util.handleNewInstance(Util.java:406) at com.mysql.jdbc.Util.getInstance(Util.java:381) at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1045) at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:956) at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3515) at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3447) at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1951) at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2101) at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2554) at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:1761) at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2046) at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:1964) at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:1949) at com.mysql.jdbc.jdbc2.optional.PreparedStatementWrapper.executeUpdate(PreparedStatementWrapper.java:874) at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:365) at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2435) ... 25 more When same thread gets reused later, it produces following exception: ERROR [org.jboss.resource.adapter.jms.inflow.JmsServerSession] (WorkManager(2)-90) org.jboss.resource.adapter.jms.inflow.Jm sServerSession$DemarcationStrategyFactory@42bae587 error creating transaction demarcation javax.transaction.NotSupportedException: BaseTransaction.checkTransactionState - [com.arjuna.ats.internal.jta.transaction.arjunacore.alreadyassocia ted] [com.arjuna.ats.internal.jta.transaction.arjunacore.alreadyassociated] thread is already associated with a transaction! at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.begin(BaseTransaction.java:80) at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.begin(BaseTransactionManagerDelegate.java:65) at org.jboss.resource.adapter.jms.inflow.JmsServerSession$XATransactionDemarcationStrategy.<init>(JmsServerSession.java:560) at org.jboss.resource.adapter.jms.inflow.JmsServerSession$DemarcationStrategyFactory.getStrategy(JmsServerSession.java:295) at org.jboss.resource.adapter.jms.inflow.JmsServerSession.createTransactionDemarcation(JmsServerSession.java:252) at org.jboss.resource.adapter.jms.inflow.JmsServerSession.run(JmsServerSession.java:224) at org.jboss.resource.work.WorkWrapper.execute(WorkWrapper.java:205) at org.jboss.util.threadpool.BasicTaskWrapper.run(BasicTaskWrapper.java:260) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) If you need any help or information, feel free to contact me. Sincerely, Teofilis Martisius -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

6
17
0 / 0

[JBoss JIRA] Created: (JBTM-842) improve XAResource recovery scan timing

by Jonathan Halliday (JIRA)

improve XAResource recovery scan timing --------------------------------------- Key: JBTM-842 URL: https://issues.jboss.org/browse/JBTM-842 Project: JBoss Transaction Manager Issue Type: Enhancement Security Level: Public (Everyone can see) Components: Recovery Affects Versions: 4.15.0 Reporter: Jonathan Halliday Assignee: Jonathan Halliday Fix For: 4.15.1 The current XAResource recovery algorithm includes a requirement that an suspect orphan Xid appear in two recovery scans before it is eligible for rollback under presumed abort. This closes the timing window where a tx branch has been prepared for normal termination but not yet committed. It's based on the assumption that the interval between scans is long enough for any normally executing tx to proceed from prepare to commit. Where the scans occur as part of consecutive recovery passes, this is generally the case. However... There are two cases in which scans can happen in quick succession, thus nullifying the safeguard and causing the recovery system to incorrectly presume abort on a branch. The first is caused by top down recovery running in the same pass before bottom up recovery. If a tx log contains an xaresourcerecord, its instantiation may cause a recovery scan. The second and more common case is where the user has incorrectly registered two or more recovery resources for the same RM. At first glance it seems possible to add a check to prevent this misconfiguration, but in practice it's not possible to write a robust comparison method that will work with all known RMs. Thus, as it is infeasible to prevent multiple scans occurring in quick succession, it is instead necessary to change the safeguard algorithm. We should require a set interval to pass after the first sighting of an Xid before considering it eligible for presumed abort, rather than requiring a given number of scan passes. This will require modification of XARecoveryModule.xaRecovery and RecoveryXids. An additional safeguard may be created by supplementing the existing transaction log based XAResourceOrphanFilter with one based on TransactionImple.getTransaction, at least for configurations where the recovery manager is running in-process. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

4
5
0 / 0

[JBoss JIRA] Created: (JBTM-686) reaper timeouts transactions early

by Jonathan Halliday (JIRA)

reaper timeouts transactions early ---------------------------------- Key: JBTM-686 URL: https://jira.jboss.org/jira/browse/JBTM-686 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: Transaction Core Affects Versions: 4.9.0 Reporter: Jonathan Halliday Assignee: Jonathan Halliday Fix For: 4.10.0 In certain situations the reaper may timeout a transaction prematurely. This is frustrating for those currently enjoying the transaction. Enhance the reaper so that premature termination is no longer a problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

2
2
0 / 0

[JBoss JIRA] Created: (JBTM-400) Compensation transactions for SOA Platform

by Mark Little (JIRA)

Compensation transactions for SOA Platform ------------------------------------------ Key: JBTM-400 URL: https://jira.jboss.org/jira/browse/JBTM-400 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: Transaction Core, WS-T Implementation Reporter: Mark Little Assignee: Mark Little Needs serious discussions within the team. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

4
8
0 / 0

[JBoss JIRA] Created: (JBTM-410) implement mixed outcome support for XTS

by Jonathan Halliday (JIRA)

implement mixed outcome support for XTS --------------------------------------- Key: JBTM-410 URL: https://jira.jboss.org/jira/browse/JBTM-410 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Components: WS-T Implementation Affects Versions: 4.4.0.GA Reporter: Jonathan Halliday Assignee: Andrew Dinn Fix For: future -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

4
6
0 / 0

[JBoss JIRA] Created: (JBTM-765) Calling activate on XTS object store records cannot be invoked safely from the ObjectStore browser

by Michael Musgrove (JIRA)

Calling activate on XTS object store records cannot be invoked safely from the ObjectStore browser -------------------------------------------------------------------------------------------------- Key: JBTM-765 URL: https://jira.jboss.org/browse/JBTM-765 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Tooling, XTS Affects Versions: 4.11.0 Reporter: Michael Musgrove Assignee: Andrew Dinn Fix For: 4.12.0 To enable inspection of XTS records via the ObjectStore browser we need a safe way to activate records (the current implementation of activate causes XTS participants to become eligible for participation in recovery which is a job best left to the recovery manager). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

5
10
0 / 0

[JBoss JIRA] Created: (JBTM-726) Change some CosTransactions exceptions to be CORBA exceptions

by Mark Little (JIRA)

Change some CosTransactions exceptions to be CORBA exceptions ------------------------------------------------------------- Key: JBTM-726 URL: https://jira.jboss.org/jira/browse/JBTM-726 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: JTS Reporter: Mark Little Assignee: Mark Little Fix For: 5.0.0 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

2
3
0 / 0

[JBoss JIRA] Created: (JBTM-668) Consider .NET interop

by Mark Little (JIRA)

Consider .NET interop --------------------- Key: JBTM-668 URL: https://jira.jboss.org/jira/browse/JBTM-668 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: TxBridge Reporter: Mark Little Assignee: Mark Little http://www.jnbridge.com/jnbpro-transactions.htm -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

2
3
0 / 0

[JBoss JIRA] Created: (JBTM-715) Improve test coverage for jts

by Mark Little (JIRA)

Improve test coverage for jts ----------------------------- Key: JBTM-715 URL: https://jira.jboss.org/jira/browse/JBTM-715 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: JTS, Testing Reporter: Mark Little Assignee: Mark Little Fix For: 4.11.0 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

2
11
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues June 2011