Remember, that both the participating (wsgen_jaxws_wsat_example) and coordinating (wsgen_jaxws_wsat_call_example) service example projects can be found over at GitHub here - https://github.com/ikromin/misc/tree/master/j2ee.
WS-AtomicTransaction Support not Enabled
Lets get started with the very obvious. What happens if you forget to enable WS-AT on your WebLogic Domain? Well, you get errors like this in the WebLogic logs...
The most interesting part of these messages is that the "http://127.0.0.1:7001/wls-wsat/RegistrationPortTypeRPC11" URL is not reachable, that's because the backend services that handle WS-AT registration and coordination haven't been deployed. To deploy them all you need to do is run some WLST. Offline mode mode is the easiest way to do it i.e. shut down your WebLogic first, run these commands and then start WebLogic. Using the same example I used in the previous two articles, with WebLogic dev server 184.108.40.206 installed in /Applications/devtools/wls_220.127.116.11, I first started WLST and then ran the following commands...
You could also choose to create your domain with the 'WebLogic Advanced Web Services for JAX-WS Extension' which will enable WS-AT support for you. Whichever way you go about enabling this support, after this step both the coordinating and participating services should work.
Calling UserTransaction.begin() in the participating service
If you call UserTransaction.begin() in the participating service, you will get an error like this...
Since the participating service is enrolled into the global transaction, there is no need to start another UserTransaction, and WebLogic doesn't support nested transactions like this. The participating service should not try to manage transactions internally - it's all handled outside that service.
Calling UserTransaction.commit() or rollback() in the participating service
Similar to the above error condition, if you call UserTransaction.commit() or UserTransaction.rollback(), you will get an exception. The reason is the same, participating services should not try to manipulate transactions directly.
That's it for now. I plan to look at the performance of WS-AT calls vs non-WS-AT calls in the future, so keep an eye out for that article!