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 <mailto: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 <mailto: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 list
Resteasy-users@lists.sourceforge.net
<mailto: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 <mailto:mmusg...@redhat.com>
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: 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
