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)
>
>
------------------------------------------------------------------------------
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
Resteasy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/resteasy-users

Reply via email to