Quarkus and transactions above multiple quarkus instances

[Tom Schindl]

Hi,

I'm  searching for a way to make a transaction span multiple services in different quarkus instances. I fully understand there's a camp of people saying that 2PC and stuff like that is a bad idea in a microservice-world but for my current business usecase it would be best option.

I have the following services:

* Service-A in quarkus-instance-A

* Service-B in quarkus-instance-B

* Service-C in quarkus-instance-C

Now I get a REST-Call into Service-A leading 2 REST-Calls to Service-B and C both of them updating a postgres-database via Hibernate. If Service-C fails I want the complete transaction rolledback.

As I'm coming from a JEE world this is roughly comparable to the following setup:

* Service-A in ejb-module-A

* Service-B in ejb-module-B

* Service-C in ejb-module-C

Here I get a REST-Call to Service-A leading to EJB-Calls to B and C and there I have nothing to do than to configure the datasource appropriately and everything just works.

My research until now brought up the following solutions:

* REST-AT: What's the state and could this be used in quarkus?

* LRA: I see the PR for quarkus was closed - https://github.com/quarkusio/quarkus/pull/6763 any further pointers how this could be done

On Twitter Mark Little mentionned that 'There's also a non-CORBA based distributed transaction (JTA) version of Narayana in WildFly/EAP but you'd have to ask the Narayana team if it's part of Quarkus.'. Is something like that available? Are there any sample repos showing one of those in a simple example?

Tom

[Michael Musgrove]

REST-AT would be a good fit for this use case. I'm busy early this week but I could take a look towards the weekend to see if we need an extension for it or whether there is a way to use REST-AT without an extension.

I will be reopening the LRA PR for quarkus as soon as we have a new release of Narayana. However, LRA does not support Isolation (ACID) so any database updates that you make in the context of a LongRunningAction will be visible to all services. On the other hand atomicity is supported by LRA which means that you could potentially write a compensation that reverts any prior database updates.

JTS is the standard specification for distributed transactions using JTA (and I am not aware of any plans to support that in Quarkus). My guess is that the "non-CORBA based distributed transaction (JTA) version of Narayana ..." refers to REST-AT. But if you have more details about that then please let me know.

--
You received this message because you are subscribed to the Google Groups "narayana-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to narayana-user...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/narayana-users/c81da808-6aa9-4554-b450-6419c5220f98n%40googlegroups.com.

--

Michael Musgrove

mmus...@redhat.com

JBoss, by Red Hat
Registered Address: Red Hat Ltd, 6700 Cork Airport Business Park, Kinsale Road, Co. Cork.
Registered in the Companies Registration Office, Parnell House, 14 Parnell Square, Dublin 1, Ireland, No.304873
Directors:Michael Cunningham (USA), Vicky Wiseman (USA), Michael O'Neill, Keith Phelan, Matt Parson (USA)

[Tom Schindl]

On Monday, January 4, 2021 at 10:53:03 AM UTC+1 mmus...@redhat.com wrote:

REST-AT would be a good fit for this use case. I'm busy early this week but I could take a look towards the weekend to see if we need an extension for it or whether there is a way to use REST-AT without an extension.

That sounds promising.

 

I will be reopening the LRA PR for quarkus as soon as we have a new release of Narayana. However, LRA does not support Isolation (ACID) so any database updates that you make in the context of a LongRunningAction will be visible to all services. On the other hand atomicity is supported by LRA which means that you could potentially write a compensation that reverts any prior database updates.

Ok - I see then REST-AT would be preferred but better than nothing ;-)

 

JTS is the standard specification for distributed transactions using JTA (and I am not aware of any plans to support that in Quarkus). My guess is that the "non-CORBA based distributed transaction (JTA) version of Narayana ..." refers to REST-AT. But if you have more details about that then please let me know.

 

I just quoted what "Mark Little" said on Twitter

Thanks for the fast feedback

Tom

[Mark Little]

Nope, I was referring to the distributed JTA implementation we have in WildFly which doesn’t use IIOP. It’s been around for a few years now.

Mark.

On 4 Jan 2021, at 09:52, Michael Musgrove <mmus...@redhat.com> wrote:

JTS is the standard specification for distributed transactions using JTA (and I am not aware of any plans to support that in Quarkus). My guess is that the "non-CORBA based distributed transaction (JTA) version of Narayana ..." refers to REST-AT. But if you have more details about that then please let me know.

---
Mark Little
mli...@redhat.com

[Michael Musgrove]

I spent today and a good chunk of yesterday on it and I "kind of got it working" (with plenty of hacking) but I did enough to show the (2PC) transaction context propagating to other (quarkus) services and showing the transaction coordinator sending transaction prepare/rollback/commit notifications to the services participating in the transaction.

I deployed the transaction coordinator to WildFly: we have a WildFly subsystem (called rts) for REST-AT in the examples directory (cp $JBOSS_HOME/docs/examples/configs/standalone-rts.xml $JBOSS_HOME/standalone/configuration). Services then interact with the coordinator using JAX-RS calls. Later on we can add support for coordinators embedded with the microservice.

The quarkus PoC will require changes to the narayana transaction manager (which is where we put the REST-AT code since it leverages the standard transaction manager code used in other products) so I won't raise a PR for a quarkus extension until we have done that although I can raise an issue asking for the new REST-AT extension if the community think this is a useful addition. If you feel that this functionality is useful for the community then what do you think the timescales for requiring the extension will be? I will try to continue the work next week.

REST-AT also supports enlisting standard XA resources into a REST-AT transaction (on the inbound path to a service), we call it the JTA bridge [4] - I haven't tested that in quarkus yet but it works fine in WildFly. We also test the basic coordinator on RestEasy and Undertow.

Note that the REST-AT coordinator itself should be pretty reliable since we use it for BlackTie [1, 2] which is an implementation of the XA XATMI implementation [3].

[1] https://docs.jboss.org/blacktie/5.0.0.M2/api/jatmibroker/index.html?org/jboss/narayana/blacktie/jatmibroker/xatmi/package-summary.html
[2] https://narayana.io//docs/project/index.html#d0e16319
[3] https://pubs.opengroup.org/onlinepubs/009649399/toc.pdf

[4] https://narayana.io//docs/project/index.html#_jta_bridge

[Michael Musgrove]

Actually if you think this feature will be a useful addition to quarkus then it would be great if the request came outside of the narayana transactions team :-)

[Tom Schindl]

that sounds very promising! Thank you very much! I'm not in a hurry to ship something tomorrow. I'll open an issue at quarkus. Is the code you crafted available somewhere so that I can point to it in the feature request?

Tom

[Michael Musgrove]

On Wed, Jan 13, 2021 at 11:41 AM Tom Schindl <toms...@gmail.com> wrote:

that sounds very promising! Thank you very much! I'm not in a hurry to ship something tomorrow. I'll open an issue at quarkus. Is the code you crafted available somewhere so that I can point to it in the feature request?

REST-AT provides an http/REST API to the narayana transaction manager and it also supports bridging to standard JTA transactions so that distributed services can enlist standard XA resources with the REST-AT transaction. The code for REST-AT is [1] and the manual is [2], currently it is deployed as war which provides endpoints for driving the lifecycle and membership of 2PC transactions. There is also a WildFly integration [3]. End user services interact with the TM using http/JAX-RS (as defined in the manual [2]), however, we also have a *prototype* PoC API that allows services to use annotations [4,5] instead of driving the lifecycle directly via http. This component [the PoC] would manage transaction context propagation (an HTTP header) and automatic enlistment (via annotation scanning) of JAX-RS services into the transaction. Quarkus users would use the annotation API [5] (but only after we have completed some further engineering work). The coordinator would be provided either as an external JAX-RS service or embedded with the service (ie one service would create the transaction/context and other services would call into that service remotely to manage it (join/commit/abort etc).

[1] https://github.com/jbosstm/narayana/tree/master/rts/at
[2] https://narayana.io//docs/project/index.html#d0e15502
[3] https://narayana.io//docs/project/index.html#_container_integration
[4] https://github.com/jbosstm/narayana/tree/master/rts/sra
[5] https://github.com/jbosstm/narayana/tree/master/rts/sra/src/main/java/io/narayana/sra/annotation

Michael 

To view this discussion on the web, visit https://groups.google.com/d/msgid/narayana-users/b66ca6c7-b7e6-4451-b4c2-f596e276d668n%40googlegroups.com.

[Tom Schindl]

Sorry for the long delay on following up but I had to finish up the showcase of the application. I filed the ticket over at Quarkus - https://github.com/quarkusio/quarkus/issues/15364