Hi Rodrigo,
Does this really have to be in the classical sense of a "distributed
transaction"? Can you not have App B embed a "undo" hypermedia link in its
response?
Given the following steps:
1) App A starts transaction and inserts some rows
2) App A makes REST call to app B
3) App B inserts rows in a separate transaction and returns a 200 response
including a "undo" hypermedia link
5) App A commits own transaction
If steps 1 or 2 fail App A rollsback transaction so no problem there.
If step 3 fails then a 500 response (or even a 4** one in case of
validation errors) will be returned in which case App A can again rollback
its transaction
If step 5 fails then App A makes a POST request to the "undo" URL
Savvas
On 2 June 2015 at 18:03, Michael Musgrove <mmusg...@redhat.com> wrote:
> 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");
> inboundBridge.start();
> 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
>
> Mike
>
> Mike,
>
> 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?
>
> Regards!
>
> On Tue, May 26, 2015 at 1:43 PM, Rodrigo Uchôa <rodrigo.uc...@gmail.com>
> wrote:
>
>> Thanks a lot, Mike! Exactly what I needed.
>>
>> On Tue, May 26, 2015 at 6:06 AM, Michael Musgrove <mmusg...@redhat.com>
>> 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].
>>>
>>>
>>> [1] http://narayana.io/documentation/
>>> [REST-AT]
>>> http://narayana.io/docs/specs/restat-v2-draft-8-2013-jul-29.pdf
>>> [2]
>>> http://narayana.io/docs/project/index.html#_interoperating_with_other_transaction_models
>>> [3] https://github.com/jbosstm/quickstart/tree/master/rts
>>> [4] https://github.com/jbosstm/quickstart/tree/master/rts/at/jta-service
>>> [5]
>>> http://narayana.io/docs/project/index.html#_support_for_java_based_services
>>> [6]
>>> http://jbossts.blogspot.co.uk/2013/07/out-of-box-support-for-restful.html
>>>
>>>
>>> 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).
>>>
>>> Mike
>>>
>>>
>>>
>>> Regards!
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> 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.http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>>>
>>>
>>>
>>> _______________________________________________
>>> Resteasy-users mailing
>>> listResteasy-users@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/resteasy-users
>>>
>>>
>>>
>>> --
>>> Michael Musgrove
>>> Red Hat UK Ltd, Transactions Team
>>> e: mmusg...@redhat.com
>>> 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)
>>>
>>>
>>
>
>
> --
> Michael Musgrove
> Red Hat UK Ltd, Transactions Team
> e: mmusg...@redhat.com
> 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
> Resteasy-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>
>
------------------------------------------------------------------------------
_______________________________________________
Resteasy-users mailing list
Resteasy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/resteasy-users
