July 2007 - jbossts-issues - Jboss List Archives

[JBoss JIRA] Closed: (JBTM-203) Interrupt reaper thread

by Andrew Dinn (JIRA)

[ http://jira.jboss.com/jira/browse/JBTM-203?page=all ] Andrew Dinn closed JBTM-203. ---------------------------- Resolution: Done Fixed in trunk: revision 13301 > Interrupt reaper thread > ----------------------- > > Key: JBTM-203 > URL: http://jira.jboss.com/jira/browse/JBTM-203 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: JTA Implementation > Affects Versions: 4.2.2 > Reporter: Mark Little > Assigned To: Andrew Dinn > Fix For: 4.4 > > > It is possible for the reaper thread to become blocked when telling a transaction to rollback. We should have another thread that interrupts the reaper thread if it has been blocked for more than a configurable amount of time on the same transaction. In this case, the reaper could either put the transaction back on the list and try again later, or just mark it as rollback_only. My preference would actually be to have a separate list of blocked transactions that are marked as rollback_only and have the reaper try to roll them back again later. -- 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

17 years, 5 months

1
0
0 / 0

[JBoss JIRA] Assigned: (JBTM-86) Exception chaining

by Mark Little (JIRA)

[ http://jira.jboss.com/jira/browse/JBTM-86?page=all ] Mark Little reassigned JBTM-86: ------------------------------- Assignee: Andrew Dinn (was: Mark Little) > Exception chaining > ------------------ > > Key: JBTM-86 > URL: http://jira.jboss.com/jira/browse/JBTM-86 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: JTA Implementation, JTS Implementation > Affects Versions: 4.2 > Reporter: Mark Little > Assigned To: Andrew Dinn > Priority: Optional > Fix For: 4.4 > > > Look at the feasibility of chaining exceptions in a distributed transaction to preseve error information. -- 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

17 years, 5 months

1
0
0 / 0

[JBoss JIRA] Work started: (JBTM-203) Interrupt reaper thread

by Andrew Dinn (JIRA)

[ http://jira.jboss.com/jira/browse/JBTM-203?page=all ] Work on JBTM-203 started by Andrew Dinn. > Interrupt reaper thread > ----------------------- > > Key: JBTM-203 > URL: http://jira.jboss.com/jira/browse/JBTM-203 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: JTA Implementation > Affects Versions: 4.2.2 > Reporter: Mark Little > Assigned To: Andrew Dinn > Fix For: 4.4 > > > It is possible for the reaper thread to become blocked when telling a transaction to rollback. We should have another thread that interrupts the reaper thread if it has been blocked for more than a configurable amount of time on the same transaction. In this case, the reaper could either put the transaction back on the list and try again later, or just mark it as rollback_only. My preference would actually be to have a separate list of blocked transactions that are marked as rollback_only and have the reaper try to roll them back again later. -- 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

17 years, 5 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBTM-104) Unify the way in which JTA default timeouts are set

by Mark Little (JIRA)

[ http://jira.jboss.com/jira/browse/JBTM-104?page=all ] Mark Little closed JBTM-104. ---------------------------- Resolution: Duplicate Issue > Unify the way in which JTA default timeouts are set > --------------------------------------------------- > > Key: JBTM-104 > URL: http://jira.jboss.com/jira/browse/JBTM-104 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: JTA Implementation, JTS Implementation, Documentation > Affects Versions: 4.2.1 > Reporter: Mark Little > Assigned To: Mark Little > Fix For: 4.4 > > > Setting of default timeout values in local JTA and remote JTA use ArjunaCore or JTS properties. We should have a jta one too for consistency across different implementations. -- 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

17 years, 5 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBTM-16) JBossWS support

by Mark Little (JIRA)

[ http://jira.jboss.com/jira/browse/JBTM-16?page=comments#action_12368234 ] Mark Little commented on JBTM-16: --------------------------------- Try JBossWS 2.0.0GA to start with. > JBossWS support > --------------- > > Key: JBTM-16 > URL: http://jira.jboss.com/jira/browse/JBTM-16 > Project: JBoss Transaction Manager > Issue Type: Task > Security Level: Public(Everyone can see) > Components: WS-T Implementation > Reporter: Mark Little > Assigned To: Jonathan Halliday > Priority: Blocker > Fix For: 4.4 > > > After the initial release of the newly integrated Arjuna Transaction Service, ensure support for JBossWS. -- 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

17 years, 5 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBTM-103) Unify default transaction timeout values

by Mark Little (JIRA)

[ http://jira.jboss.com/jira/browse/JBTM-103?page=comments#action_12368229 ] Mark Little commented on JBTM-103: ---------------------------------- In ArjunaJTA BaseTransaction.begin: Integer value = (Integer) _timeouts.get(ThreadUtil.getThreadId()); int v = 0; // if not set then assume 0. What else can we do? if (value != null) { v = value.intValue(); } // TODO set default timeout which doesn't exist in the JTAX BaseTransaction, because that relies on the JTS Current object to manage timeouts, which pulls the default from the JTS property and not the ArjunaCore property (check relevant Environment.java classes to see what I mean). The JTA and JTS implementations should both use the Core definition of default transaction timeout. At the moment, if someone wants to set a default timeout for JTA transactions, that should be used if no explicit timeout is defined, they can only do so via the JTS implementation. Plus, they'd need to make sure the JTS value is the same as the Core value if they want to mix and match transaction implementations (not likely in reality). We should have only a single place to set the default transaction timeout, and this value should be used when no timeout is explicitly defined. A value of 0 or -1 should be taken as "no timeout", i.e., infinite. JTS TransactionFactory does this already: int theTimeout = time_out; if (theTimeout == 0) theTimeout = TransactionFactoryImple._defaultTimeout; and _defaultTimeout could be 0. > Unify default transaction timeout values > ---------------------------------------- > > Key: JBTM-103 > URL: http://jira.jboss.com/jira/browse/JBTM-103 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: JTA Implementation, JTS Implementation > Affects Versions: 4.2.1 > Reporter: Mark Little > Assigned To: Mark Little > Fix For: 4.4 > > > Default transaction timeout values for local and remote JTA implementations are different. -- 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

17 years, 5 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBTM-103) Unify default transaction timeout values

by Jonathan Halliday (JIRA)

[ http://jira.jboss.com/jira/browse/JBTM-103?page=comments#action_12368213 ] Jonathan Halliday commented on JBTM-103: ---------------------------------------- Mark I'm not clear on this one. The effective default timeout appears to be 0 regardless of which TransactionManagerImple is used. Am I missing something? > Unify default transaction timeout values > ---------------------------------------- > > Key: JBTM-103 > URL: http://jira.jboss.com/jira/browse/JBTM-103 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: JTS Implementation, JTA Implementation > Affects Versions: 4.2.1 > Reporter: Mark Little > Assigned To: Mark Little > Fix For: 4.4 > > > Default transaction timeout values for local and remote JTA implementations are different. -- 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

17 years, 5 months

1
0
0 / 0

[JBoss JIRA] Assigned: (JBTM-203) Interrupt reaper thread

by Mark Little (JIRA)

[ http://jira.jboss.com/jira/browse/JBTM-203?page=all ] Mark Little reassigned JBTM-203: -------------------------------- Assignee: Andrew Dinn (was: Mark Little) > Interrupt reaper thread > ----------------------- > > Key: JBTM-203 > URL: http://jira.jboss.com/jira/browse/JBTM-203 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: JTA Implementation > Affects Versions: 4.2.2 > Reporter: Mark Little > Assigned To: Andrew Dinn > Fix For: 4.4 > > > It is possible for the reaper thread to become blocked when telling a transaction to rollback. We should have another thread that interrupts the reaper thread if it has been blocked for more than a configurable amount of time on the same transaction. In this case, the reaper could either put the transaction back on the list and try again later, or just mark it as rollback_only. My preference would actually be to have a separate list of blocked transactions that are marked as rollback_only and have the reaper try to roll them back again later. -- 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

17 years, 6 months

1
0
0 / 0

[JBoss JIRA] Assigned: (JBTM-246) Release WS-Context implementation and re-factor

by Mark Little (JIRA)

[ http://jira.jboss.com/jira/browse/JBTM-246?page=all ] Mark Little reassigned JBTM-246: -------------------------------- Assignee: Mark Little (was: Jonathan Halliday) > Release WS-Context implementation and re-factor > ----------------------------------------------- > > Key: JBTM-246 > URL: http://jira.jboss.com/jira/browse/JBTM-246 > Project: JBoss Transaction Manager > Issue Type: Task > Security Level: Public(Everyone can see) > Components: WS-T Implementation > Reporter: Mark Little > Assigned To: Mark Little > Fix For: 4.4 > > > The ESB architecture has a notion of a message context. In Web Services, the standard approach for this is OASIS WS-Context. Although our ESB is not tied to Web Services, it makes sense that we should support WS-Context. We already have an implementation that has been tested for interoperability with IONA and Oracle, so this is a good starting point. It will need some updating to bring it in line with the latest version of the specification. -- 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

17 years, 6 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBTM-246) Release WS-Context implementation and re-factor

by Mark Little (JIRA)

[ http://jira.jboss.com/jira/browse/JBTM-246?page=all ] Mark Little closed JBTM-246. ---------------------------- Resolution: Duplicate Issue > Release WS-Context implementation and re-factor > ----------------------------------------------- > > Key: JBTM-246 > URL: http://jira.jboss.com/jira/browse/JBTM-246 > Project: JBoss Transaction Manager > Issue Type: Task > Security Level: Public(Everyone can see) > Components: WS-T Implementation > Reporter: Mark Little > Assigned To: Mark Little > Fix For: 4.4 > > > The ESB architecture has a notion of a message context. In Web Services, the standard approach for this is OASIS WS-Context. Although our ESB is not tied to Web Services, it makes sense that we should support WS-Context. We already have an implementation that has been tested for interoperability with IONA and Oracle, so this is a good starting point. It will need some updating to bring it in line with the latest version of the specification. -- 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

17 years, 6 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 July 2007