February 2013 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-1481) Transaction::commit on an transaction that the reaper has tried to rollback but has a wedged resource will not raise an exception

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1481?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1481: -------------------------------- Attachment: (was: output.log) > Transaction::commit on an transaction that the reaper has tried to rollback but has a wedged resource will not raise an exception > --------------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-1481 > URL: https://issues.jboss.org/browse/JBTM-1481 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 4.6.1.CP13 > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 4.6.1.CP14 > > > If you are getting a wedged resource. What then happens is that we interrupt the original reaper thread that is calling XAResource::rollback on the wedged resource which because you are using JacORB and have an in progress call will generate a null pointer exception when the thread is interrupted (you can see this in my attached log file, it prints a stack trace where the logging didn't do so before) which generates a org.omg.CORBA.TRANSACTION_ROLLEDBACK exception. > The problem is that after the reaper tries to rollback the transaction but stalls on a wedged resource, it is then possible for the app thread to unwedged and to do a JTA::commit() and not get an exception. Debugging through the code, it doesn't pose data integrity issues on the transaction as what is happening is that internally we are checking the status of the transaction: > ./ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/coordinator/ArjunaTransactionImple.java:340 > And because the transaction is not RUNNING or ABORT_ONLY, we are: > ./ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/coordinator/ArjunaTransactionImple.java:398: > throw new INVALID_TRANSACTION(0, CompletionStatus.COMPLETED_NO) > Which is all good so far but then ends up in: > ./ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/TransactionImple.java:1425 > catch (INVALID_TRANSACTION e6) > { > /* > * In JTS/OTS we can indicate that something was terminated by another thread. > * JTA doesn't really prevent this, but ... > */ > > //throw new IllegalStateException( > // jtaLogger.loggerI18N.getString("com.arjuna.ats.internal.jta.transaction.jts.invalidtx2")); > } > Where it appears at some point we would have thrown an exception but decided to make the call that this was not valid anymore. > As I say, it doesn't pose data integrity implications to the specific transaction, but if your app thread unwedges and you then make a decision on the outcome of the transaction (send email, acknowledge success) then it would break the business rules of that application. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-1481) Transaction::commit on an transaction that the reaper has tried to rollback but has a wedged resource will not raise an exception

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1481?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1481: -------------------------------- Attachment: (was: WedgedResourceDemonstrator.java) > Transaction::commit on an transaction that the reaper has tried to rollback but has a wedged resource will not raise an exception > --------------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-1481 > URL: https://issues.jboss.org/browse/JBTM-1481 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 4.6.1.CP13 > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 4.6.1.CP14 > > Attachments: output.log > > > If you are getting a wedged resource. What then happens is that we interrupt the original reaper thread that is calling XAResource::rollback on the wedged resource which because you are using JacORB and have an in progress call will generate a null pointer exception when the thread is interrupted (you can see this in my attached log file, it prints a stack trace where the logging didn't do so before) which generates a org.omg.CORBA.TRANSACTION_ROLLEDBACK exception. > The problem is that after the reaper tries to rollback the transaction but stalls on a wedged resource, it is then possible for the app thread to unwedged and to do a JTA::commit() and not get an exception. Debugging through the code, it doesn't pose data integrity issues on the transaction as what is happening is that internally we are checking the status of the transaction: > ./ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/coordinator/ArjunaTransactionImple.java:340 > And because the transaction is not RUNNING or ABORT_ONLY, we are: > ./ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/coordinator/ArjunaTransactionImple.java:398: > throw new INVALID_TRANSACTION(0, CompletionStatus.COMPLETED_NO) > Which is all good so far but then ends up in: > ./ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/TransactionImple.java:1425 > catch (INVALID_TRANSACTION e6) > { > /* > * In JTS/OTS we can indicate that something was terminated by another thread. > * JTA doesn't really prevent this, but ... > */ > > //throw new IllegalStateException( > // jtaLogger.loggerI18N.getString("com.arjuna.ats.internal.jta.transaction.jts.invalidtx2")); > } > Where it appears at some point we would have thrown an exception but decided to make the call that this was not valid anymore. > As I say, it doesn't pose data integrity implications to the specific transaction, but if your app thread unwedges and you then make a decision on the outcome of the transaction (send email, acknowledge success) then it would break the business rules of that application. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-1407) Have a build option that builds JTS only against JacORB or IDLJ, but not both.

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/JBTM-1407?page=com.atlassian.jira.plugin.... ] Gytis Trikleris updated JBTM-1407: ---------------------------------- Fix Version/s: 5.0.0.M3 (was: 5.0.0.M2) > Have a build option that builds JTS only against JacORB or IDLJ, but not both. > ------------------------------------------------------------------------------ > > Key: JBTM-1407 > URL: https://issues.jboss.org/browse/JBTM-1407 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: JTS > Affects Versions: 4.17.3 > Reporter: Mark Little > Assignee: Gytis Trikleris > Fix For: 5.0.0.M3 > > Time Spent: 3 days, 1 hour, 50 minutes > Remaining Estimate: 1 hour > > This boils down to supporting two new profiles: > ./build.sh -P jts-jacorb > ./build.sh -P jts-idlj -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-1477) Migrate TXF subsytem contents into relavent transport subsytem

by Paul Robinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1477?page=com.atlassian.jira.plugin.... ] Paul Robinson commented on JBTM-1477: ------------------------------------- Check interceptor ordering. Need to be as un-disruptve as possible. > Migrate TXF subsytem contents into relavent transport subsytem > -------------------------------------------------------------- > > Key: JBTM-1477 > URL: https://issues.jboss.org/browse/JBTM-1477 > Project: JBoss Transaction Manager > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Application Server Integration, TXFramework, XTS > Reporter: Paul Robinson > Assignee: Paul Robinson > Fix For: 5.0.0.M2 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > E.g. > XTS stuff into xts subsytem and REST-AT stuff (when it exists) into the rts subsytem (when it exists). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-1477) Migrate TXF subsytem contents into relavent transport subsytem

by Paul Robinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1477?page=com.atlassian.jira.plugin.... ] Paul Robinson commented on JBTM-1477: ------------------------------------- Add copyright header too. > Migrate TXF subsytem contents into relavent transport subsytem > -------------------------------------------------------------- > > Key: JBTM-1477 > URL: https://issues.jboss.org/browse/JBTM-1477 > Project: JBoss Transaction Manager > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Application Server Integration, TXFramework, XTS > Reporter: Paul Robinson > Assignee: Paul Robinson > Fix For: 5.0.0.M2 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > E.g. > XTS stuff into xts subsytem and REST-AT stuff (when it exists) into the rts subsytem (when it exists). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-1481) Transaction::commit on an transaction that the reaper has tried to rollback but has a wedged resource will not raise an exception

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1481?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1481: -------------------------------- Attachment: output.log WedgedResourceDemonstrator.java > Transaction::commit on an transaction that the reaper has tried to rollback but has a wedged resource will not raise an exception > --------------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-1481 > URL: https://issues.jboss.org/browse/JBTM-1481 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 4.6.1.CP13 > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 4.6.1.CP14 > > Attachments: output.log, WedgedResourceDemonstrator.java > > > If you are getting a wedged resource. What then happens is that we interrupt the original reaper thread that is calling XAResource::rollback on the wedged resource which because you are using JacORB and have an in progress call will generate a null pointer exception when the thread is interrupted (you can see this in my attached log file, it prints a stack trace where the logging didn't do so before) which generates a org.omg.CORBA.TRANSACTION_ROLLEDBACK exception. > The problem is that after the reaper tries to rollback the transaction but stalls on a wedged resource, it is then possible for the app thread to unwedged and to do a JTA::commit() and not get an exception. Debugging through the code, it doesn't pose data integrity issues on the transaction as what is happening is that internally we are checking the status of the transaction: > ./ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/coordinator/ArjunaTransactionImple.java:340 > And because the transaction is not RUNNING or ABORT_ONLY, we are: > ./ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/coordinator/ArjunaTransactionImple.java:398: > throw new INVALID_TRANSACTION(0, CompletionStatus.COMPLETED_NO) > Which is all good so far but then ends up in: > ./ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/TransactionImple.java:1425 > catch (INVALID_TRANSACTION e6) > { > /* > * In JTS/OTS we can indicate that something was terminated by another thread. > * JTA doesn't really prevent this, but ... > */ > > //throw new IllegalStateException( > // jtaLogger.loggerI18N.getString("com.arjuna.ats.internal.jta.transaction.jts.invalidtx2")); > } > Where it appears at some point we would have thrown an exception but decided to make the call that this was not valid anymore. > As I say, it doesn't pose data integrity implications to the specific transaction, but if your app thread unwedges and you then make a decision on the outcome of the transaction (send email, acknowledge success) then it would break the business rules of that application. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-1481) Transaction::commit on an transaction that the reaper has tried to rollback but has a wedged resource will not raise an exception

by Tom Jenkinson (JIRA)

Tom Jenkinson created JBTM-1481: ----------------------------------- Summary: Transaction::commit on an transaction that the reaper has tried to rollback but has a wedged resource will not raise an exception Key: JBTM-1481 URL: https://issues.jboss.org/browse/JBTM-1481 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 4.6.1.CP13 Reporter: Tom Jenkinson Assignee: Tom Jenkinson Priority: Critical Fix For: 4.6.1.CP14 If you are getting a wedged resource. What then happens is that we interrupt the original reaper thread that is calling XAResource::rollback on the wedged resource which because you are using JacORB and have an in progress call will generate a null pointer exception when the thread is interrupted (you can see this in my attached log file, it prints a stack trace where the logging didn't do so before) which generates a org.omg.CORBA.TRANSACTION_ROLLEDBACK exception. The problem is that after the reaper tries to rollback the transaction but stalls on a wedged resource, it is then possible for the app thread to unwedged and to do a JTA::commit() and not get an exception. Debugging through the code, it doesn't pose data integrity issues on the transaction as what is happening is that internally we are checking the status of the transaction: ./ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/coordinator/ArjunaTransactionImple.java:340 And because the transaction is not RUNNING or ABORT_ONLY, we are: ./ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/coordinator/ArjunaTransactionImple.java:398: throw new INVALID_TRANSACTION(0, CompletionStatus.COMPLETED_NO) Which is all good so far but then ends up in: ./ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/TransactionImple.java:1425 catch (INVALID_TRANSACTION e6) { /* * In JTS/OTS we can indicate that something was terminated by another thread. * JTA doesn't really prevent this, but ... */ //throw new IllegalStateException( // jtaLogger.loggerI18N.getString("com.arjuna.ats.internal.jta.transaction.jts.invalidtx2")); } Where it appears at some point we would have thrown an exception but decided to make the call that this was not valid anymore. As I say, it doesn't pose data integrity implications to the specific transaction, but if your app thread unwedges and you then make a decision on the outcome of the transaction (send email, acknowledge success) then it would break the business rules of that application. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-1440) Move the XTS documentation into the /docs folder and check they are current

by Paul Robinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1440?page=com.atlassian.jira.plugin.... ] Paul Robinson commented on JBTM-1440: ------------------------------------- Tom has suggested that we should split the document into: # WS-TX Theory: Community only # XTS dev and admin (Remainder of docs): Product & Community (same document) > Move the XTS documentation into the /docs folder and check they are current > --------------------------------------------------------------------------- > > Key: JBTM-1440 > URL: https://issues.jboss.org/browse/JBTM-1440 > Project: JBoss Transaction Manager > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Documentation, XTS > Affects Versions: 4.17.3 > Reporter: Tom Jenkinson > Assignee: Paul Robinson > Fix For: 4.17.4, 5.0.0.M2 > > Original Estimate: 1 day > Time Spent: 5 hours > Remaining Estimate: 3 hours > > It appears that there is no need to split the documentation between community/product, see JBTM-835 for details. It may be worth double checking it is all still product related, if not, leave some in XTS/docs and move the relevant parts into /docs/XTS? > We should also use this as an opportunity to check that the docs are current. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-1440) Move the XTS documentation into the /docs folder and check they are current

by Paul Robinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1440?page=com.atlassian.jira.plugin.... ] Paul Robinson edited comment on JBTM-1440 at 2/20/13 11:10 AM: --------------------------------------------------------------- Tom has suggested that we should split the document into: # WS-TX Theory: Community only # XTS dev and admin (Remainder of docs): Product & Community (same document) This is in-line with the structuring on the other transactions docs. was (Author: paul.robinson): Tom has suggested that we should split the document into: # WS-TX Theory: Community only # XTS dev and admin (Remainder of docs): Product & Community (same document) > Move the XTS documentation into the /docs folder and check they are current > --------------------------------------------------------------------------- > > Key: JBTM-1440 > URL: https://issues.jboss.org/browse/JBTM-1440 > Project: JBoss Transaction Manager > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Documentation, XTS > Affects Versions: 4.17.3 > Reporter: Tom Jenkinson > Assignee: Paul Robinson > Fix For: 4.17.4, 5.0.0.M2 > > Original Estimate: 1 day > Time Spent: 5 hours > Remaining Estimate: 3 hours > > It appears that there is no need to split the documentation between community/product, see JBTM-835 for details. It may be worth double checking it is all still product related, if not, leave some in XTS/docs and move the relevant parts into /docs/XTS? > We should also use this as an opportunity to check that the docs are current. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-1477) Migrate TXF subsytem contents into relavent transport subsytem

by Paul Robinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1477?page=com.atlassian.jira.plugin.... ] Paul Robinson updated JBTM-1477: -------------------------------- Fix Version/s: 5.0.0.M2 > Migrate TXF subsytem contents into relavent transport subsytem > -------------------------------------------------------------- > > Key: JBTM-1477 > URL: https://issues.jboss.org/browse/JBTM-1477 > Project: JBoss Transaction Manager > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Application Server Integration, TXFramework, XTS > Reporter: Paul Robinson > Assignee: Paul Robinson > Fix For: 5.0.0.M2 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > E.g. > XTS stuff into xts subsytem and REST-AT stuff (when it exists) into the rts subsytem (when it exists). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues February 2013