Hi, maybe this is a very basic question, but I'm doing some test with the txBridge and don't understand something and I suppose this could help me a bit. What's the relationship/difference between JaxWSHeaderContextProcessor and JaxWSTransactionBridgeHandler?
That's actually a fairly advanced question and a good one too.
The things that they have in common are
-- they look for a transaction context in the headers of an incoming JaxWS request. a transaction context essentially identifies a transaction by i) type and ii) unique identifier.
-- if they find a transaction context they ensure that the handler thread executes inside the correct transaction
The differnece is that
-- JaxWSHeaderContextProcessor sets up the handler thread to run in the same transaction as the one whose details were passed in the transaction context.
-- JaxWSTransactionBridgeHandler sets up the handler thread to run in a separate, dependent JTA transaction.
JaxWSHeaderContextProcessor looks for details of a WS-AT transaction (or a WS-BA activity) in the message headers. If it finds any it sets up the handler thread so that it runs inside the same ransaction as the JaxWS client. So, if the JaxWS service method tries to enlist an AT participant then the enlist message gets routed to the coordinator which the client talked to when it started the transaction. This means that when the client commits the transaction the participant will get told to prepare and then commit (or possibly to rollback if some other participant failed to prepare).
JaxWSHeaderContextProcessor does the same sort of thing if the incoming message contains details of a WS-BA activity. The handler thread is set up to run inside the BA transaction and an enlist of a BA participant will be routted to the BA ccordinator that the client is talking to. The enlsited partiicipant may be sent complete, close, cancel or compensated requests by the BA cooridnator. The service handler can also use the object returned from the enlist to send completed, failed and cannot complete messages to the coordinator.
JaxWSTransactionBridgeHandler currently only looks looks for details of a WS-AT transaction in the message headers, If it finds any it sets up the handler thread so that it runs inside a JTAtransaction. The JTA transaction is created by JaxWSTransactionBridgeHandler the first time a WS-AT txid is seen in an incoming JaxWS message. If several JaxWS requests are made using the same WS-AT txid then the second, third etc calls use the JTA transaction created on the first call.
The coordinator for the JTA transaction runs in the VM of the JaxWS service. If the service handler thread tries to enlist an XA resource then it gets enlisted with this VM-local JTA transaction. The handler thread may enlist several resources under one service request. Or a single resource may be enlisted on each of several requests. Either way you may end up with several XA resources involved in the JTA transaction.
The service handler threads are not allowed to commit or rollback the JTA transaction directly. Instead the JTA transaction is managed by a wrapper object created by JaxWSTransactionBridgeHandler when it creates the JTA transaction. This is called a bridge participant because it is enlisted as a WS-AT participant with the WS-AT transaction identified in the JaxWS service request and it also has a handle on the JTA transaction. It talks upwards to the WS-AT coordinator and downwards to the XA resources via the JTA coordinator.
When the client commits the WS-AT transaction the bridge participant gets sent a prepare message. it passes this message on to the JTA coordinator and the JTA coordinator tells all its enlisted XA resources to prepare. If they all succeed the bridge participant returns a prepared message to the WS-AT coordinator. If any of then fails it returns a failed message.
If all the other participants in the WS-AT transaction prepare ok then the WS-AT coordinator sends a commit message to the bridge participant and it tells the JTA coordinator to commit all enlisted resources. After they commit the bridge participant sends back a committed message. If the bridge participant any other WS-AT participant returned failed the WS-AT coordinator sends a rollback message to the bridge participant which tells the JTA coordinator to rollback all its XA resources. After they have done this the bridge participant sends an aborted message back to the WS-AT coordinator.
A similar sort of thing can be tried if details of a BA transaction are found in the first incoming JaxWS service request. The only problem is that it is not simple to translate incoming completed, close, cancel and compensate requests to JTA prepare, commit and rollback requests. We do not yet have a BA --> JTA bridge implementation but we are planning to implement it soon.
Hi adinn! First of all, thank you very much for this details explanation of each concept. I don't know which what plans has JBoss for this bridge, but this info is very usefull and would be very helpfull to have it on the wiki or similar.
Another thing related to this, is that I've been looking for this clases in JBossTM 4.7 GA but didn't found them. Are they independent of JBossTM? If they are, are there any plans to integrate them to the framework near soon?