I am not sure this will always be the best solution if the inserts at
the two servers need to be treated as a single business operation.
The solution you propose means that the inserts do not happen atomically
and therfore you will put Consistency and Isolation at risk - ie other
applications will see some of the inserts before both transactions have
committed.
Mike
Hi Rodrigo,
Does this really have to be in the classical sense of a "distributed
transaction"? Can you not have App B embed a "undo" hypermedia link in
its response?
Given the following steps:
1) App A starts transaction and inserts some rows
2) App A makes REST call to app B
3) App B inserts rows in a separate transaction and returns a 200
response including a "undo" hypermedia link
5) App A commits own transaction
If steps 1 or 2 fail App A rollsback transaction so no problem there.
If step 3 fails then a 500 response (or even a 4** one in case of
validation errors) will be returned in which case App A can again
rollback its transaction
If step 5 fails then App A makes a POST request to the "undo" URL
Savvas
On 2 June 2015 at 18:03, Michael Musgrove <mmusg...@redhat.com
<mailto:mmusg...@redhat.com>> wrote:
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 <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)
------------------------------------------------------------------------------
_______________________________________________
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
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
