REST-AT and JTA are different transaction models. Unfortunately we only provide an "inbound bridge" to go from REST-AT to JTA but I think you need the other direction ie JTA to REST-AT.

There may be a workaround for you though which I would need to experiment with. You would need to start a REST-AT transaction and emulate what we do with the "inbound bridge" by manually starting a bridge. Something similar to:

1) EJB in web app A will start a REST-AT transaction
2) EJB in web app A will start an InboundBridge (instead of the JTA transaction): InboundBridge inboundBridge = InboundBridgeManager.getInstance().createInboundBridge("enlistmentUrl from step 1");
3) EJB in web app A will perform JTA work (insert some records in a database)
4) invoke REST endpoint in app B passing the enlistmentUrl in a Link header
5) Mark up the REST endpoint in app B (using the javax.transaction.Transactional annotation) - this will automatically start an instance of the inbound bridge 6) commit the REST-AT transaction started in step 1. This will cause the work done in B and in A to commit within the context of the single REST-AT transaction.

The only other ways to we have for distributed transactions are:

- "distributed remoting protocol" for JTA (think EJBs)
- and of course we JTS too;
- web services transactions (XTS, WS-AT)
- BlackTie for C based clients



I have been reading the docs and taking a look at the code samples. I'm still unsure however if the protocol/api covers the scenario I'm in:

I have a client web app (A), and a REST endpoint (B). Two separate applications. Client in web app A is not a REST endpoint itself, just a regular stateless EJB.

So in my scenario the stateless EJB in web app A will start a transaction, insert some records in a database and invoke REST endpoint in app B, which in turn will also run a transaction to insert records in a database. We need to make sure these two transactions are atomic. That meaning, the two transactions should be only one.

To me it seems that the protocol only covers scenarios where both participants in the transaction are REST resources, which in my case is not true. The client needs to participate in the transaction and it's just a regular EJB.

Is this really the case?


On Tue, May 26, 2015 at 1:43 PM, Rodrigo Uchôa < <>> wrote:

    Thanks a lot, Mike! Exactly what I needed.

    On Tue, May 26, 2015 at 6:06 AM, Michael Musgrove
    < <>> wrote:

        The narayana transaction manager has a rest service that
        creates [transaction] Coordinator resources. These resources
        map onto conventional ACID transactions. It is up to your
        service to decide what to do when the "transaction" is
        completing. However, we also have a "JTA Bridge" that will
        detect when your JAX-RS service performs JTA work (JMS, JPA
        etc) and automatically enlist those XA participants with the
        currently active coordinator.

        Our on-line docs [1] contains descriptions of the [REST-AT]
        protocol and our implementation of it including a small
        section on the bridge [2]. We have a number of quickstarts [3]
        that show it action including a quickstart that demonstrates
        how to enable and use the JTA (inbound) bridge [4].

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


        I have an web application "A" that occasionally have to
        insert/update records that belong to another application,
        "B". To manage this requirement, application "B" expose some
        REST endpoints that application "A" will call whenever it needs.

        Problem is, we need to make sure that the inserts/updates
        occurring in both applications are atomic.

        Does anyone have done something similar and can point a
        solution? I know that there's a debate whether transactions
        in REST are conceptually wrong, but we're willing to break
        the rules in this case.

        OK let's not go there then (but when you say "we're willing to
        break the rules" you are already tacitly stating on which side
        of the argument you stand).



        One dashboard for servers and applications across Physical-Virtual-Cloud
        Widest out-of-the-box monitoring support with 50+ applications
        Performance metrics, stats and reports that give you Actionable Insights
        Deep dive visibility with transaction tracing using APM Insight.;117567292;y

        Resteasy-users mailing list  

-- Michael Musgrove
        Red Hat UK Ltd, Transactions Team  <>
        t:+44 191 243 0870  <tel:%2B44%20191%20243%200870>

        Registered in England and Wales under Company Registration No. 03798903
        Directors: Michael Cunningham (US), Charles Peters (US), Matt Parson 
(US), Michael O'Neill(Ireland)

Michael Musgrove
Red Hat UK Ltd, Transactions Team
t: +44 191 243 0870

Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham (US), Charles Peters (US), Matt Parson (US), 
Michael O'Neill(Ireland)

Resteasy-users mailing list

Reply via email to