Guys, Once again, thank you both for your help.
Savvas, that's really an option we're considering. But like Michael said, it would be just a workaround, not really an "atomic transaction". But it is indeed one option. I'm still trying to weight which of the two pays off. Regards, Rodrigo. On Mon, Jun 8, 2015 at 8:28 AM, Michael Musgrove <mmusg...@redhat.com> wrote: > 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> 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> >> wrote: >> >>> 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  contains descriptions of the [REST-AT] protocol >>>> and our implementation of it including a small section on the bridge . >>>> We have a number of quickstarts  that show it action including a >>>> quickstart that demonstrates how to enable and use the JTA (inbound) bridge >>>> . >>>> >>>> We also provide an integration API  that abstracts the mechanics of >>>> participating in REST-AT transactions - there is a high level description >>>> of it on our team blog . >>>> >>>> >>>>  http://narayana.io/documentation/ >>>> [REST-AT] >>>> http://narayana.io/docs/specs/restat-v2-draft-8-2013-jul-29.pdf >>>>  >>>> http://narayana.io/docs/project/index.html#_interoperating_with_other_transaction_models >>>>  https://github.com/jbosstm/quickstart/tree/master/rts >>>>  >>>> https://github.com/jbosstm/quickstart/tree/master/rts/at/jta-service >>>>  >>>> http://narayana.io/docs/project/index.html#_support_for_java_based_services >>>>  >>>> 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 >>>> listResteasyemail@example.com://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) >>>> >>>> >>> >> >> >> -- >> 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 >> Resteasyfirstname.lastname@example.org >> 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 Resteasyemail@example.com https://lists.sourceforge.net/lists/listinfo/resteasy-users