REST-AT and Container-Managed Transactions

[juan_a_velez]

Hello,

We are researching ways of using microservices and REST and one of the issues we'd like to solve is the transactional aspect of it (We'd like to keep using XA/JTA/ACID as opposed to Compensation-Based TXs) and I found that there is in fact Transactions for REST.

I started reading/learning about Narayana's REST-AT and I after reading/testing the Quickstarts (quickstart/rts/at at master · jbosstm/quickstart · GitHub) most specifically the ones that deal with JTA (quickstart/rts/at/jta-service at master · jbosstm/quickstart · GitHub), I'd like to confirm that in order to use REST-AT, the "initiation" of a transaction needs to happen manually, this is, there is no way for the Container to manage the life-cycle of such transaction.

Since we rely on Container-Managed Transactions, I don't know if it is possible to annotate our service methods such as they become part of the REST-AT transactions.

Anyway, please pardon my ignorance on the subject. Trying to learn.

Thanks

Juan

[mmusgrov]

We don't currently support automatically starting REST-AT transactions. We decided against that because the service that creates coordinators (aka begin a transaction) could reside anywhere on the network.

I guess we could check to see if the current container has such a service deployed and if it did then start a "local" REST-AT transaction. But then we would need an api to expose the resulting urls to the service method.

Related is our support for an inbound bridge:- if a JAX-RS service method is annotated as transactional and the incoming http request has a link header containing a REST-AT transaction enlistment url then we will make sure that any JTA work performed by the service call becomes part of the REST-AT transaction.

[mmusgrov]

John, is your requirement to simply have transactional JAX-RS services. If so then you just need to add JTA 1.2 transaction annotations to your JAX-RS service methods and you do not need to use REST-AT

[juan_a_velez]

Thanks for the explanation. Our use case would be that a Stateless Bean(in this case a REST one) would be called by a client and we did not want the client to be "burdened" by having to know that a REST-AT transaction needs to take place.

Regarding your last comment the idea of using REST-AT is because we want to manage transactions among different microservices which may reside in different app servers. In our monotithic, JBoss-based application, we use extensively CMT (using JTA annotations) in our stateless beans(REST and non-REST ones).

[juan_a_velez]

Michael, is there a link to learn about the inbound bridge you talk about?

Thanks,

Juan

[mmusgrov]

Our on-line docs contain a small section on the bridge. The quickstart you referred to demonstrates how to enable and use it.

We also provide an integration API that abstracts the mechanics of participating in REST-AT transactions - there is a high level description of it on our team blog.

If you have any other suggestions or ideas about how we can improve the usablitly of REST-AT please let us know.