[
https://issues.jboss.org/browse/JBTM-981?page=com.atlassian.jira.plugin.s...
]
Paul Robinson updated JBTM-981:
-------------------------------
Description:
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
# 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.
was:
!!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.
!!Example
# 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.
#
Annotation support for transaction bridging
-------------------------------------------
Key: JBTM-981
URL:
https://issues.jboss.org/browse/JBTM-981
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Reporter: Paul Robinson
Assignee: Paul Robinson
Labels: TXFramework
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
# 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.
--
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