August 2011 - jbossts-issues - Jboss List Archives

[JBoss JIRA] Created: (JBTM-264) Improve tooling

by Mark Little (JIRA)

Improve tooling --------------- Key: JBTM-264 URL: http://jira.jboss.com/jira/browse/JBTM-264 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Tooling Affects Versions: 4.2.3.SP5 Reporter: Mark Little Assigned To: Mark Little Priority: Critical We need better tools support. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

3
7
0 / 0

[JBoss JIRA] Created: (JBTM-785) Document configuration of standalone client

by Andrew Dinn (JIRA)

Document configuration of standalone client ------------------------------------------- Key: JBTM-785 URL: https://jira.jboss.org/browse/JBTM-785 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 4.12.0 Reporter: Andrew Dinn Assignee: Andrew Dinn Need to explain how to set up standalone client so it can be deployed embedded without the need to expose completion initiator service endpoints. -- 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, 8 months

6
12
0 / 0

[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, 8 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, 10 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-861) XTS AS7 configuration is incomplete and inadequate for binding/web port other than localhost:8080

by Andrew Dinn (JIRA)

XTS AS7 configuration is incomplete and inadequate for binding/web port other than localhost:8080 ------------------------------------------------------------------------------------------------- Key: JBTM-861 URL: https://issues.jboss.org/browse/JBTM-861 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Components: XTS Affects Versions: 4.15.2 Reporter: Andrew Dinn Fix For: 4.15.3, 5.0.0.M1 The current integration of XTS into AS7 as an AS7 extension allows optional configuration of the coordinator URL from the <xts/> element in the AS7 standalone configuration file. No other configuration options are currently supported. This is inadequate on two counts. Firstly, if no URL is provided the coordinator address is located via localhost:8080 (or localhost:8443 if an https scheme is employed). Similarly, the deployed web services are assumed to have localhost:8080 addresses. The XTS extension ought to depend on JBoss web and use the bind address and ports (non-secure and secure) JBoss web employs. Secondly, XTS ought to support more precise configuration. IN particular, it ought to be possible to enable or disable deployment of coordinator, participant or client services independently and also to choose whether to deploy WS-AT or WS-BA services or both. This requires selectively deploying only the required web service endpoints, selectively executing the required initialization routines and selectively loading the required high level service implementations and context factory implementations. The XTS implementation has already been factored so as to to support such discriminated bootstrapping. So this task only requires modifying the AS7 extension code to manage the relevant configuration information and install the relevant values into the XTS environment configuration beans before starting the XTS service. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

5
19
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, 1 month

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

13 years, 1 month

4
5
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues August 2011