November 2010 - jbossts-issues - Jboss List Archives

[JBoss JIRA] Created: (JBTM-741) Remove redundant XTS classes and code paths identified from coverage data

by Andrew Dinn (JIRA)

Remove redundant XTS classes and code paths identified from coverage data ------------------------------------------------------------------------- Key: JBTM-741 URL: https://jira.jboss.org/jira/browse/JBTM-741 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: XTS Affects Versions: 4.11.0 Reporter: Andrew Dinn Assignee: Andrew Dinn Fix For: future Coverage analysis of the XTS code base has idenitifed a lot of unexercised classes and code paths. These need pruning in order to simplify maintenance and testing. -- 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, 9 months

4
9
0 / 0

[JBoss JIRA] Created: (JBTM-802) XTS BA coordinator drops completed as per spec but causes long delay for web service compensation

by Andrew Dinn (JIRA)

XTS BA coordinator drops completed as per spec but causes long delay for web service compensation ------------------------------------------------------------------------------------------------- Key: JBTM-802 URL: https://jira.jboss.org/browse/JBTM-802 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.6.1.CP08, 4.13.0 Reporter: Andrew Dinn Assignee: Andrew Dinn Fix For: 4.14.0, 4.6.1.CP09 The WSBA spec requires a coordinator to drop completed requests from a web service belonging to an unknown transaction. The idea is that the web service eventually gets bored and sends a getstatus message to see if the transacton is still valid at which point the coordinator dispatches an invalid state fault initiating compensation at the web service end. The problem is that timeing out the resending of completed and switching to sending getstatus is a tricky business. Done too early it can cause ping-ponging back and forth from completed to getstatus. Too late and it means it takes a long time before compensation is done. It is not clear from the spec that completed cannot also legitimately send an invalid state fault when it sees completed from an unknown participant. If so then doing this would significantly speed up recovery. This needs investigating to check that it will not cause interop problems and, if it is permissible, should be implemented. -- 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, 11 months

8
21
0 / 0

[JBoss JIRA] Created: (JBTM-396) Provide one-phase commit optimization

by Mark Little (JIRA)

Provide one-phase commit optimization ------------------------------------- Key: JBTM-396 URL: https://jira.jboss.org/jira/browse/JBTM-396 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Components: WS-T Implementation Affects Versions: 4.4.CR1 Reporter: Mark Little Assignee: Andrew Dinn WS-AT does not support 1PC optimization. WS-ACID from WS-CAF does. It would be good to provide a configurable option for WS-AT users to enable 1PC optimization. This obviously breaks interoperability, which is why the default should be to have it disabled. -- 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

13 years

5
7
0 / 0

[JBoss JIRA] Created: (JBTM-713) Provide a general annotation-based Transaction Framework based on the BA Framework prototype

by Andrew Dinn (JIRA)

Provide a general annotation-based Transaction Framework based on the BA Framework prototype -------------------------------------------------------------------------------------------- Key: JBTM-713 URL: https://jira.jboss.org/jira/browse/JBTM-713 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: Application Server Integration, Common, Demonstrator, Documentation, Recovery, Transaction Core, TxBridge, XTS Affects Versions: 4.9.0 Reporter: Andrew Dinn Assignee: Andrew Dinn The prototype BA Transaction Management Framework has been useful in clarifying how JBossTS can simplify some of the tasks developers must perform when designing and implementing of transactional services. However, the prototype suffers from various limitations, both in its definition and its implementation. An alternative framework, preferably one which can embrace multiple transaction protocols (and not just Web Service transactions), needs to be defined, developed and then incorporated into the TS release. -- 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

13 years

6
11
0 / 0

[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

13 years

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

13 years, 2 months

6
17
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

13 years, 3 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

13 years, 3 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

13 years, 3 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

13 years, 3 months

5
10
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues November 2010