November 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] (JBTM-977) Specify the order in which lifecycle methods are invoked when multiple of the same type exist

by Paul Robinson (Created) (JIRA)

Specify the order in which lifecycle methods are invoked when multiple of the same type exist --------------------------------------------------------------------------------------------- Key: JBTM-977 URL: https://issues.jboss.org/browse/JBTM-977 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Components: TxBridge Reporter: Paul Robinson Assignee: Paul Robinson Fix For: 5.0.0.M2 A LifecycleClass implementation should be able to register multiple methods with the same Lifecycele annotation. For example, this would allow more than one compensation method to be triggered. Example: {code} @ServiceRequest() public void submitOrder(...) { ... } @Compensate public void cancelOrder() { //Cancel the order } @Compensate public void notifyAdmin() { //Notify an admin that an order was cancelled. } {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

2
4
0 / 0

[JBoss JIRA] (JBTM-982) Support transaction annotations of POJOs via the TXFramework

by Paul Robinson (Created) (JIRA)

Support transaction annotations of POJOs via the TXFramework ------------------------------------------------------------- Key: JBTM-982 URL: https://issues.jboss.org/browse/JBTM-982 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Paul Robinson Assignee: Paul Robinson Fix For: 5.0.0.M2 h2.Vision The grand plan for this feature is to support near transparent bridging, end-to-end irrespective of what transport and component technology is used. The only caveat being that the transport and component technologies support a compatible transaction model. The basic case would be to always bridge when possible and for this scenario the absolute bare-minimum number of annotations should be used. More specific bridging requirements should be specified through annotations. h2.Example This example shows what is considered the default scenario. It requires very few annotations. # A JSF managed bean has a client to Service1 injected. # The managed bean begins a transaction. # Service1 uses WSPolicy to state that it requires a WSAT transaction to be in place. # Somehow (maybe during injection or when CXF handles the PolicyAssertion) the injected client stub for Service1 has the TXBridge and XTS interceptors configured. # The managed bean invokes a method on Service1. # The JTA transaction is bridged to a WS-AT transaction and the Web service request is made. # Service1 specified by an annotation that it requires a transaction (this was how the WS-Policy assertion was placed in the WSDL) and thus the XTS and TXBridge interceptors are inserted. # The incoming WS-AT context is detected and bridged onto a JTA transaction. # Service1 updates a DB and the associated XAResource is enlisted with the JTA transaction. # Service1 then invokes the client of Service2. # Service2 does not specify that it requires a WS-AT transaction, via a WS-Policy assertion. Therefore the client to Service2 must be annotated to specify that it requires WS-AT transaction out-flow. # When invoking a method on the Service2 client it is detected that a WS-AT transaction is already in-place and this is used, rather than bridging again from JTA back to WS-AT. Similar behaviour should occur for REST and JTS transactions also. h2.Advanced features This section describes some of the more advanced features that could be supported. As these features deviate from the default scenario, they are all specified by annotations. h1. Specific "bridged from" protocol In the default scenario the transaction protocol bridged from is inferred by the transaction context present when the service is invoked. As a result any supported transaction will enact bridging. Some services may need to limit the types of transactions they bridge from. For example, only enable bridging if a WS-BA transaction is in place prior to service invocation. h1. Specific "bridged to" protocol The default is to always bridge to JTA for incoming bridging. However, this could be inefficient if a Web service always invokes another Web service, both requiring WS-AT. There may be other situations where bridging to JTA is not appropriate. h1. Disable bridging The service may wish to prevent bridging altogether. For example if no transactional work needs to be done within a different type of transaction. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

2
3
0 / 0

[JBoss JIRA] (JBTM-976) CLONE - Allow many ServiceRequest methods to have a single set of Lifecycle methods

by Paul Robinson (Created) (JIRA)

CLONE - Allow many ServiceRequest methods to have a single set of Lifecycle methods ----------------------------------------------------------------------------------- Key: JBTM-976 URL: https://issues.jboss.org/browse/JBTM-976 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Components: TxBridge Reporter: Paul Robinson Assignee: Paul Robinson Fix For: 5.0.0.M2 By default if no LifecycleClass is specified on the @ServiceRequest then the same LifecycleClass is registered for each @ServiceRequest method. However, a different instance of the class is registered for each @ServiceRequest method. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

2
5
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] (JBTM-979) Support REST-JDI protocol in the TXFramework

by Paul Robinson (Created) (JIRA)

Support REST-JDI protocol in the TXFramework --------------------------------------------- Key: JBTM-979 URL: https://issues.jboss.org/browse/JBTM-979 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Paul Robinson Assignee: Paul Robinson Fix For: 5.0.0.M2 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

2
2
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] (JBTM-17) Rebadge existing Arjuna Transaction Service training material

by Paul Robinson (Updated) (JIRA)

[ https://issues.jboss.org/browse/JBTM-17?page=com.atlassian.jira.plugin.sy... ] Paul Robinson updated JBTM-17: ------------------------------ Fix Version/s: 5.0.0.Final (was: 5.0.0.M2) > Rebadge existing Arjuna Transaction Service training material > ------------------------------------------------------------- > > Key: JBTM-17 > URL: https://issues.jboss.org/browse/JBTM-17 > Project: JBoss Transaction Manager > Issue Type: Task > Security Level: Public(Everyone can see) > Components: JTA, JTS, XTS > Reporter: Mark Little > Assignee: Paul Robinson > Priority: Minor > Fix For: 5.0.0.Final > > Time Spent: 2 hours > Remaining Estimate: 0 minutes > > Re-badge training material and collateral (presentations, white papers, etc.) Currently docs are distributed in pdf format. Is this a problem? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-974) Allow many ServiceRequest methods to have a single set of Lifecycle methods

by Paul Robinson (Created) (JIRA)

Allow many ServiceRequest methods to have a single set of Lifecycle methods --------------------------------------------------------------------------- Key: JBTM-974 URL: https://issues.jboss.org/browse/JBTM-974 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Components: TxBridge Reporter: Paul Robinson Assignee: Paul Robinson Fix For: 5.0.0.M2 The lifecycleClass attribute on @ServiceRequest and @ParticipantService needs to support remote services, such as EJB or Web services. This allows the events to be handled in a remote container. We need to decide how and what context is passed to the remote service. Clearly the remote service needs some context to know what action to take. However, simply flowing the TX context may not be appropriate as the lifecycle methods will be invoked during termination of the protocol. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

2
5
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues November 2011