Menu
▾
▴
Re: [Resteasy-users] Distributed transactions with REST resources
|
From: Michael M. <mmu...@re...> - 2015-06-02 17:03:20
|
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... <mailto:rod...@gm...>> wrote:
>
> Thanks a lot, Mike! Exactly what I needed.
>
> On Tue, May 26, 2015 at 6:06 AM, Michael Musgrove
> <mmu...@re... <mailto: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 list
>> Res...@li... <mailto:Res...@li...>
>> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>
>
> --
> Michael Musgrove
> Red Hat UK Ltd, Transactions Team
> e:mmu...@re... <mailto:mmu...@re...>
> 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
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)
|
