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 <rodrigo.uc...@gmail.com>

> 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)
Resteasy-users mailing list

Reply via email to