Hi Rodrigo,
Well, I'm thinking that if your requirements are such that your application
cannot tolerate an eventual consistency of such a level then probably a
more "traditional" XA type of solution would be more appropriate for your
circumstances.
HTH,
Savvas
On 8 June 2015 at 19:02, Rodrigo Uchôa <rodrigo.uc...@gmail.com> wrote:
> 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 <mmusg...@redhat.com>
> 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 <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
>>>
>>>
>>
>>
>> --
>> 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
