[JBoss JIRA] (JBTM-1467) Create a set of Koans for using Compensations
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1467?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson closed JBTM-1467.
-------------------------------
Fix Version/s: (was: 6.later)
Resolution: Rejected
> Create a set of Koans for using Compensations
> ---------------------------------------------
>
> Key: JBTM-1467
> URL: https://issues.jboss.org/browse/JBTM-1467
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Components: TXFramework, XTS
> Reporter: Paul Robinson
>
> In the spirit of http://rubykoans.com/, but to learn how to use compensations.
> In the long term we should use a Java EE Koan 'runner'. In the short term, try using Arquillian with some broken tests. We could do something to intercept logs for an appropriate error message to present the user.
> Might also be worth having Arquillian stop on a failed test to prevent too many failures swamping the user.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 5 months
[JBoss JIRA] (JBTM-1099) WS-BA to 2xJTA bridge
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1099?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1099:
--------------------------------
Fix Version/s: (was: 6.later)
> WS-BA to 2xJTA bridge
> ---------------------
>
> Key: JBTM-1099
> URL: https://issues.jboss.org/browse/JBTM-1099
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Components: TXFramework
> Reporter: Paul Robinson
> Labels: assign
> Original Estimate: 1 week
> Time Spent: 3 hours
> Remaining Estimate: 4 days, 5 hours
>
> It is likely that a WS using WS-BA will use a JTA transaction in the service, Compensate and Close methods. The problem is that failure windows exist in this scenario. For example, when a JTA transaction is committed in the service method, a failure before confirmCompleted(true) is invoked will result in this commit not being compensated.
> There may be other windows in Compensate and Close. This needs investigating.
> The WS-BA to JTA bridge would ensure that the transaction is not committed until confirmCompleted(true) is invoked. It should do something similar for Compensate and Close.
> This would need extensive testing, including crash recovery. The WS-AT JTA bridge (TXBridge) can be used as an example, as I believe it will have a lot in common.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 5 months
[JBoss JIRA] (JBTM-1099) WS-BA to 2xJTA bridge
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1099?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1099:
--------------------------------
Component/s: TxBridge
XTS
(was: TXFramework)
> WS-BA to 2xJTA bridge
> ---------------------
>
> Key: JBTM-1099
> URL: https://issues.jboss.org/browse/JBTM-1099
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Components: TxBridge, XTS
> Reporter: Paul Robinson
> Labels: assign
> Original Estimate: 1 week
> Time Spent: 3 hours
> Remaining Estimate: 4 days, 5 hours
>
> It is likely that a WS using WS-BA will use a JTA transaction in the service, Compensate and Close methods. The problem is that failure windows exist in this scenario. For example, when a JTA transaction is committed in the service method, a failure before confirmCompleted(true) is invoked will result in this commit not being compensated.
> There may be other windows in Compensate and Close. This needs investigating.
> The WS-BA to JTA bridge would ensure that the transaction is not committed until confirmCompleted(true) is invoked. It should do something similar for Compensate and Close.
> This would need extensive testing, including crash recovery. The WS-AT JTA bridge (TXBridge) can be used as an example, as I believe it will have a lot in common.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 5 months
[JBoss JIRA] (JBTM-1104) XTS support for load-balanced scenarios
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1104?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1104:
--------------------------------
Fix Version/s: (was: 6.later)
> XTS support for load-balanced scenarios
> ---------------------------------------
>
> Key: JBTM-1104
> URL: https://issues.jboss.org/browse/JBTM-1104
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Components: XTS
> Reporter: Paul Robinson
>
> Enabling session affinity on the load balancer should ensure that all requests for a particular application endpoint, within a particular session, go to the same instance of the web service.
> However, XTS advertises a number of endpoint addresses that will not make sense in a load balanced cluster. This is because it would be the internal endpoint address of the particular server that is advertised, rather than the load balancer's external address.
> Even if we configured XTS (not yet possible) to offer the address of the LB, we would still have a problem as XTS will use a different session to the application to send protocol messages and thus they will go to a different server that is not aware of this transaction.
> h4. Potential Solution
> For each web service that is deployed by XTS, we advertises a modified version of the load balancer's address. The modification to the url provides a unique identifier for the particular node in the cluster. The load balancer would then be configured to route messages based on the modification in the url. The LB would also re-write the URL to match that expected by the particular server that receives the message.
> This should be configurable per group of services provided by XTS (Client, Coordinator, Participant) as not all of these will, necessarily, be exposed via the LB.
> Each Service offered by XTS is deployed via JBossWS. XTS also maintains metadata about the endpoint which it advertises to other participants in the protocol. This metadata is currently kept in sync with the service, but it doesn't have to be. In this situation, the metadata could be configured to advertise the LB address, rather than the actual address of the service. This is also where the URL re-writing would occur to identify the individual node. An example of a class that creates the endpoint metadata is "RegistrationCoordinatorInitialisation".
> I don't know what support popular load balancers have for the type of URL re-writing that I mention here. This should be investigated.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 5 months