July 2011 - jbossts-issues - Jboss List Archives

[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

12 years, 4 months

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

12 years, 4 months

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

12 years, 4 months

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

12 years, 4 months

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

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, 7 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, 7 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, 7 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues July 2011