January 2009 - jbossts-issues - Jboss List Archives

[JBoss JIRA] Created: (JBTM-478) WSAT participant recovery does not reinitiate dispatch of recovered participant messages to coordinator

by Andrew Dinn (JIRA)

WSAT participant recovery does not reinitiate dispatch of recovered participant messages to coordinator -------------------------------------------------------------------------------------------------------- Key: JBTM-478 URL: https://jira.jboss.org/jira/browse/JBTM-478 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: WS-T Implementation Affects Versions: 4.5 Reporter: Andrew Dinn Fix For: 4.6 When the AT recovery code re-activates a participant after a crash it omits to call recovery() which initiates resend of PREPARED messages to the coordinator. So, recovery only succeeds if it is initiated top-down. This fails if the one phase optimization is employed since the coordinator does not log the transaction after receiving the PREPARED messages (in this case the coordinator would send rollback when it received the PREPARED) . Ditto for two phase if the coordinator crashes before receiving all PREPARED messages. -- 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

16 years

1
5
0 / 0

[JBoss JIRA] Updated: (JBTM-44) Transaction bridging

by Waldemar K?aczy?ski (JIRA)

[ https://jira.jboss.org/jira/browse/JBTM-44?page=com.atlassian.jira.plugin... ] Waldemar K?aczy?ski updated JBTM-44: ------------------------------------ Attachment: jbossxts-bridge.zip I created a similar project for JBossTS 4.5.0 GA. For the purposes of this exercise, extend it for implementation of JTS, WS-T 1.0, and wrote to him documentation. Do not go into JBossJTS checked, but I guess that because of the almost identical code should not be problems. The prototype, for the moment works fine. Since I have access to the repo, so I'm sending zipped project compiled using ant. > Transaction bridging > -------------------- > > Key: JBTM-44 > URL: https://jira.jboss.org/jira/browse/JBTM-44 > Project: JBoss Transaction Manager > Issue Type: Task > Security Level: Public(Everyone can see) > Components: JTA Implementation, JTS Implementation, WS-T Implementation > Reporter: Mark Little > Assignee: Jonathan Halliday > Priority: Critical > Fix For: 4.6 > > Attachments: jbossxts-bridge.zip > > -- 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

16 years

1
0
0 / 0

[JBoss JIRA] Created: (JBTM-471) WSBA recovery implementation does not correctly handle crashes between complete and close

by Andrew Dinn (JIRA)

WSBA recovery implementation does not correctly handle crashes between complete and close ----------------------------------------------------------------------------------------- Key: JBTM-471 URL: https://jira.jboss.org/jira/browse/JBTM-471 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: WS-T Implementation Affects Versions: 4.5 Reporter: Andrew Dinn Fix For: 4.6 The current WSBA client API allows the client to invoke the complete operation independent from the close operation. In the current persistence implementation complete is implemented, inter alia, by calling BasicAction.prepare and close is implemented by calling BasicAction.phase2Commit.. The call to BasicAction.prepare leaves a transaction record in the log in state COMMITTING rather than state PREPARED. If a crash occurs before the client sends a close request then the recovery code will attempt to roll forward the activity by calling phase2Commit even though the client has not yet requested that the close should happen. If the client dispatches the close request after the recovery code has run it will receive a NoSuchTransaction exception which is highly misleading since the activity has in fact been successfully closed. The correct behaviour is only to call BasicAction.prepare during close processing. If complete processing is necessare (i.e if there are CoordinatorCompletion participants registered) then the exchange of complete/completed messages should be done by the BA Coordinator class before it attempts to execute a close. The close itself should be implemented by calling BasicAction.End to perform a 2 phase commit. This will ensure that a log record is only written when a close for the activity has been initiated and hence that any record written after the prepare will initiate a valid roll forward of the activity during recovery. -- 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

16 years

1
2
0 / 0

[JBoss JIRA] Created: (JBTM-479) update XTS build for AS 5.1

by Jonathan Halliday (JIRA)

update XTS build for AS 5.1 --------------------------- Key: JBTM-479 URL: https://jira.jboss.org/jira/browse/JBTM-479 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: Application Server Integration, WS-T Implementation Affects Versions: 4.5 Reporter: Jonathan Halliday Assignee: Jonathan Halliday Fix For: 4.6 The AS has moved the servlet API, which XTS compiles against. Update the XTS build scripts so they can find it. -- 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

16 years

1
1
0 / 0

[JBoss JIRA] Created: (JBTM-463) WS-AT can leak participant-side log entries when committing with only one participant

by Andrew Dinn (JIRA)

WS-AT can leak participant-side log entries when committing with only one participant ------------------------------------------------------------------------------------- Key: JBTM-463 URL: https://jira.jboss.org/jira/browse/JBTM-463 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.5 Reporter: Andrew Dinn Assignee: Andrew Dinn The WSAT coordinator implements its client commit operation by calling BasicAction.End(). End() calls BasicAction.doOnePhase() to decide whether to optimise the commit. If there is only one participant then doOnePhase() will return true in which case End() calls the participant record's method topLevelOnePhaseCommit() to do the commit and omits to write a log record for the transaction. The WSAT participant record can only perform this one phase commit by dispatching a prepare message followed by a commit message (this is required by the AT spec). The participant has to log a participant record at prepare. If the coordinator JVM crashes between prepare and commit then the participant web service will never delete the log record because it will never receive a commit message when the coordinator restarts. n.b. this can easily be fixed by overriding BasicAction.doOnePhase in the WSAT coordinator so that it returns false. however, this method is final so modifying it requires a change to the signature of BasicAction. -- 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

16 years

2
8
0 / 0

[JBoss JIRA] Created: (JBTM-476) Make ControlWrapper handle reaped remote transactions more gracefully

by Mark Little (JIRA)

Make ControlWrapper handle reaped remote transactions more gracefully --------------------------------------------------------------------- Key: JBTM-476 URL: https://jira.jboss.org/jira/browse/JBTM-476 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: JTS Implementation Affects Versions: 4.5 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

16 years

1
1
0 / 0

[JBoss JIRA] Created: (JBTM-475) Cache transaction status in local case when it is destroyed

by Mark Little (JIRA)

Cache transaction status in local case when it is destroyed ----------------------------------------------------------- Key: JBTM-475 URL: https://jira.jboss.org/jira/browse/JBTM-475 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Components: JTS Implementation Affects Versions: 4.5 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

16 years

1
1
0 / 0

[JBoss JIRA] Created: (JBTM-473) ControlWrapper failed to set status to NoTransaction on suspending null association

by Mark Little (JIRA)

ControlWrapper failed to set status to NoTransaction on suspending null association ----------------------------------------------------------------------------------- Key: JBTM-473 URL: https://jira.jboss.org/jira/browse/JBTM-473 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: JTS Implementation Affects Versions: 4.5 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

16 years

1
1
0 / 0

[JBoss JIRA] Created: (JBTM-474) Change ControlWrapper.getStatus to not default to NoTransaction

by Mark Little (JIRA)

Change ControlWrapper.getStatus to not default to NoTransaction --------------------------------------------------------------- Key: JBTM-474 URL: https://jira.jboss.org/jira/browse/JBTM-474 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: JTS Implementation Affects Versions: 4.5 Reporter: Mark Little Assignee: Mark Little Fix For: 4.6 Currently returns NoTransaction. Should be StatusUnknown or Rolledback. -- 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

16 years

1
1
0 / 0

[JBoss JIRA] Created: (JBTM-472) OTSImple could not cope with null control for resume

by Mark Little (JIRA)

OTSImple could not cope with null control for resume ---------------------------------------------------- Key: JBTM-472 URL: https://jira.jboss.org/jira/browse/JBTM-472 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: JTS Implementation Affects Versions: 4.5 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

16 years

1
2
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues January 2009