Re: [Resteasy-users] Distributed transactions with REST resources

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Guys,

Once again, thank you both for your help.

Savvas, that's really an option we're considering. But like Michael said,
it would be just a workaround, not really an "atomic transaction". But it
is indeed one option. I'm still trying to weight which of the two pays off.

Regards,
Rodrigo.

On Mon, Jun 8, 2015 at 8:28 AM, Michael Musgrove <mmu...@re...>
wrote:

>  I am not sure this will always be the best solution if the inserts at
> the two servers need to be treated as a single business operation.
>
> The solution you propose means that the inserts do not happen atomically
> and therfore you will put Consistency and Isolation at risk - ie other
> applications will see some of the inserts before both transactions have
> committed.
>
> Mike
>
>  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 <mmu...@re...> 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 <rod...@gm...>
>> wrote:
>>
>>> Thanks a lot, Mike! Exactly what I needed.
>>>
>>> On Tue, May 26, 2015 at 6:06 AM, Michael Musgrove <mmu...@re...>
>>> 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 lis...@li...://lists.sourceforge.net/lists/listinfo/resteasy-users
>>>>
>>>>
>>>>
>>>> --
>>>> Michael Musgrove
>>>> Red Hat UK Ltd, Transactions Team
>>>> e: mmu...@re...
>>>> 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: mmu...@re...
>> 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
>> Res...@li...
>> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>>
>>
>
>
> --
> Michael Musgrove
> Red Hat UK Ltd, Transactions Team
> e: mmu...@re...
> 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)
>
>