[JBoss JIRA] (JBTM-1479) Create a quickstart to show how to use IronJacamar and JBTM inside tomcat
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-1479?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris updated JBTM-1479:
----------------------------------
Description:
See JBTM-809 for the algorithm
You might want to put the startup in the context listener:
public class MyServletContextListener implements ServletContextListener {
public void contextInitialized(ServletContextEvent sce) {
// Initialize RecoveryManager
// Initialize TransactionManager
// Initialize IronJacamar
}
@Override
public void contextDestroyed(ServletContextEvent sce) {
// Clean IronJacamar
// Clean TransactionManager
// Clean RecoveryManager
}
}
Quickstart application should connect to the database (say PostgreSQL), dummy XA resource and coordinate the transaction. The PostgreSQL data source needs to be accessed via IronJacamar.
was:
See JBTM-809 for the algorithm
You might want to put the startup in the context listener:
public class MyServletContextListener implements ServletContextListener {
public void contextInitialized(ServletContextEvent sce) {
// Initialize RecoveryManager
// Initialize TransactionManager
// Initialize IronJacamar
}
@Override
public void contextDestroyed(ServletContextEvent sce) {
// Clean IronJacamar
// Clean TransactionManager
// Clean RecoveryManager
}
}
> Create a quickstart to show how to use IronJacamar and JBTM inside tomcat
> -------------------------------------------------------------------------
>
> Key: JBTM-1479
> URL: https://issues.jboss.org/browse/JBTM-1479
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Tom Jenkinson
> Assignee: Gytis Trikleris
> Fix For: 5.0.0.M2
>
> Attachments: test-ds.xml, transaction.xml
>
>
> See JBTM-809 for the algorithm
> You might want to put the startup in the context listener:
> public class MyServletContextListener implements ServletContextListener {
> public void contextInitialized(ServletContextEvent sce) {
> // Initialize RecoveryManager
> // Initialize TransactionManager
> // Initialize IronJacamar
> }
>
> @Override
> public void contextDestroyed(ServletContextEvent sce) {
> // Clean IronJacamar
> // Clean TransactionManager
> // Clean RecoveryManager
> }
> }
> Quickstart application should connect to the database (say PostgreSQL), dummy XA resource and coordinate the transaction. The PostgreSQL data source needs to be accessed via IronJacamar.
--
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
[JBoss JIRA] (JBTM-1479) Create a quickstart to show how to use IronJacamar and JBTM inside tomcat
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-1479?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris updated JBTM-1479:
----------------------------------
Description:
See JBTM-809 for the algorithm
You might want to put the startup in the context listener:
public class MyServletContextListener implements ServletContextListener {
public void contextInitialized(ServletContextEvent sce) {
// Initialize RecoveryManager
// Initialize TransactionManager
// Initialize IronJacamar
}
@Override
public void contextDestroyed(ServletContextEvent sce) {
// Clean IronJacamar
// Clean TransactionManager
// Clean RecoveryManager
}
}
Quickstart application should connect to the database (say PostgreSQL), dummy XA resource and coordinate the transaction. The PostgreSQL data source needs to be accessed via IronJacamar.
was:
See JBTM-809 for the algorithm
You might want to put the startup in the context listener:
public class MyServletContextListener implements ServletContextListener {
public void contextInitialized(ServletContextEvent sce) {
// Initialize RecoveryManager
// Initialize TransactionManager
// Initialize IronJacamar
}
@Override
public void contextDestroyed(ServletContextEvent sce) {
// Clean IronJacamar
// Clean TransactionManager
// Clean RecoveryManager
}
}
> Create a quickstart to show how to use IronJacamar and JBTM inside tomcat
> -------------------------------------------------------------------------
>
> Key: JBTM-1479
> URL: https://issues.jboss.org/browse/JBTM-1479
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Tom Jenkinson
> Assignee: Gytis Trikleris
> Fix For: 5.0.0.M2
>
> Attachments: test-ds.xml, transaction.xml
>
>
> See JBTM-809 for the algorithm
> You might want to put the startup in the context listener:
> public class MyServletContextListener implements ServletContextListener {
> public void contextInitialized(ServletContextEvent sce) {
> // Initialize RecoveryManager
> // Initialize TransactionManager
> // Initialize IronJacamar
> }
>
> @Override
> public void contextDestroyed(ServletContextEvent sce) {
> // Clean IronJacamar
> // Clean TransactionManager
> // Clean RecoveryManager
> }
> }
> Quickstart application should connect to the database (say PostgreSQL), dummy XA resource and coordinate the transaction. The PostgreSQL data source needs to be accessed via IronJacamar.
--
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
[JBoss JIRA] (JBTM-1479) Create a quickstart to show how to use IronJacamar and JBTM inside tomcat
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-1479?page=com.atlassian.jira.plugin.... ]
Work on JBTM-1479 started by Gytis Trikleris.
> Create a quickstart to show how to use IronJacamar and JBTM inside tomcat
> -------------------------------------------------------------------------
>
> Key: JBTM-1479
> URL: https://issues.jboss.org/browse/JBTM-1479
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Tom Jenkinson
> Assignee: Gytis Trikleris
> Fix For: 5.0.0.M2
>
> Attachments: test-ds.xml, transaction.xml
>
>
> See JBTM-809 for the algorithm
> You might want to put the startup in the context listener:
> public class MyServletContextListener implements ServletContextListener {
> public void contextInitialized(ServletContextEvent sce) {
> // Initialize RecoveryManager
> // Initialize TransactionManager
> // Initialize IronJacamar
> }
>
> @Override
> public void contextDestroyed(ServletContextEvent sce) {
> // Clean IronJacamar
> // Clean TransactionManager
> // Clean RecoveryManager
> }
> }
--
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
[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 updated JBTM-1440:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> 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: 1 day
> Remaining Estimate: 0 minutes
>
> 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
[JBoss JIRA] (JBTM-986) Automatically setup the client side handler chain
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-986?focusedWorklogId=12428715&page=c... ]
Gytis Trikleris logged work on JBTM-986:
----------------------------------------
Author: Gytis Trikleris
Created on: 21/Feb/13 6:15 AM
Start Date: 21/Feb/13 6:15 AM
Worklog Time Spent: 30 minutes
Issue Time Tracking
-------------------
Remaining Estimate: 1 day, 7 hours, 30 minutes (was: 2 days)
Time Spent: 1 week, 3 days, 1 hour, 30 minutes (was: 1 week, 3 days, 1 hour)
Worklog Id: (was: 12428715)
> Automatically setup the client side handler chain
> -------------------------------------------------
>
> Key: JBTM-986
> URL: https://issues.jboss.org/browse/JBTM-986
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: XTS
> Reporter: Paul Robinson
> Assignee: Gytis Trikleris
> Labels: assign
> Fix For: 5.0.0.M2
>
> Original Estimate: 4 days
> Time Spent: 1 week, 3 days, 1 hour, 30 minutes
> Remaining Estimate: 1 day, 7 hours, 30 minutes
>
> When invoking a WS-AT or WS-BA Web service, the client side handler has to be added to the client stub to manage transaction context propagation. The code required to do this is as follows:
> {code}
> BindingProvider bindingProvider = (BindingProvider) client;
> List<Handler> handlers = new ArrayList<Handler>(1);
> handlers.add(new JaxWSHeaderContextProcessor());
> bindingProvider.getBinding().setHandlerChain(handlers);
> {code}
> This is not very user friendly.
> This could be done using a JAX-WS feature passed to the Client-side port.
> We also need to support client stubs created using @WebServiceRef. Here's some examples of its use:
> http://anonsvn.jboss.org/repos/jbossws/shared-testsuite/trunk/testsuite/s...
> http://anonsvn.jboss.org/repos/jbossws/shared-testsuite/trunk/testsuite/s...
> http://anonsvn.jboss.org/repos/jbossws/shared-testsuite/trunk/testsuite/s...
> The feature should be "enabled" by default providing the feature is enabled in the XTS server config.
> The quickstarts also need updated to use this.
--
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
[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?focusedWorklogId=12428714&page=... ]
Paul Robinson logged work on JBTM-1440:
---------------------------------------
Author: Paul Robinson
Created on: 21/Feb/13 6:13 AM
Start Date: 21/Feb/13 6:13 AM
Worklog Time Spent: 3 hours
Issue Time Tracking
-------------------
Remaining Estimate: 0 minutes (was: 3 hours)
Time Spent: 1 day (was: 5 hours)
Worklog Id: (was: 12428714)
> 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: 1 day
> Remaining Estimate: 0 minutes
>
> 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
[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: WedgedResourceDemonstrator.java
JBTM-1481.patch
The test case confirms this only affects JTS.
JTA is able to cope with this for two reasons:
1. It is more eager to treat random exceptions from the XAResource as a failure
2. When commit is called on a rolled back transaction it locally checks if the transaction is in state rollback or rolling back and then performs a second attempted abort which the system detects and returns the correct error code
The attached patch fixes both of these (the stack trace is to be consistent with the JTA version to ensure the "logging api" remains consistent for detecting this case).
> 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: JBTM-1481.patch, 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