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
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)
------------------------------------------------------------------------------
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
