14 Replies Latest reply on Jul 6, 2015 12:28 PM by gytis

accessing docker image based JBoss Transaction Manager as a service from a Weld/CDI based docker image

peterfry Jun 22, 2015 6:45 AM

I've become aware of

https://issues.jboss.org/browse/JBTM-2267

If I understand the motivation for this correctly it should allow transaction services to be accessed as a service.

Weld has SPI hooks that allows different transaction managers to be plugged in (the obvious example being the JBoss AS 7 / Wildfly SPI).

Is there any work ongoing or is it reasonable to hope to be able to do the following:

Deploy a CDI application (i.e. one packaged as a jar not a war or ear) as a docker image with any transactions being managed by the transaction manager described in this JIRA ticket.

i.e. where use of the Transactional CDI annotation in a CDI Java SE application results in the use of a transaction manager located in a separate docker image.

i.e. all transactions being XA (or some other distributed transaction processing mechanism) but with the wiring of the transaction services being managed by kubernetes .

It would be a great quickstart/demo .

Thanks,

Peter.

1. Re: accessing docker image based JBoss Transaction Manager as a service from a Weld/CDI based docker image

marklittle Jun 22, 2015 8:34 AM (in response to peterfry)

Whilst it's not using Docker directly, have you looked at WildFly-Swarm?
1 of 1 people found this helpful
Actions
2. Re: accessing docker image based JBoss Transaction Manager as a service from a Weld/CDI based docker image

gytis Jun 22, 2015 9:13 AM (in response to peterfry)

Hi Peter,

another options is to use our JTS + JacORB Name Server images.They're still in my personal repo. But any input about what's missing in it would be great. narayana-docker/jts/transaction-service at master · gytis/narayana-docker · GitHub .
And the small quickstart is here: quickstart/jts-docker at master-JBTM-2296 · gytis/quickstart · GitHub.

Gytis
1 of 1 people found this helpful
Actions
3. Re: accessing docker image based JBoss Transaction Manager as a service from a Weld/CDI based docker image

peterfry Jun 22, 2015 9:52 AM (in response to marklittle)

Mark,

So two separate Wildfly-Swarm images for two separate microservices with one transaction starting in one swarm image propogating to another swarm image then you could choose between remote EJBs or JAX-RS with REST-AT.

This does remove the need for a Transactions as Service though (since each microservices is hosting a transaction service)?

Peter
Actions
4. Re: accessing docker image based JBoss Transaction Manager as a service from a Weld/CDI based docker image

tomjenkinson Jun 22, 2015 11:10 AM (in response to peterfry)

There is also RTS (REST-AT) as a docker image over here: narayana/rts-wildfly at master · jboss-dockerfiles/narayana · GitHub. It's worth pointing out that that RTS image uses the RTS standalone.xml from WildFly which does seem to start up the whole server too: wildfly/rts.xml at master · wildfly/wildfly · GitHub - as you probably know, WildFly launches incredibly quickly so the additional services shouldn't add too much overhead to the boot time but gytis - it might be worth trying to slim that rts.xml to just include the services that are required to fire up RTS itself?
Actions
5. Re: accessing docker image based JBoss Transaction Manager as a service from a Weld/CDI based docker image

marklittle Jun 22, 2015 1:25 PM (in response to peterfry)

Again ignoring Docker for the moment, you could deploy one WF-Swarm instance with some business logic and then have another instance(s) that uses the same transaction manager running within the first. Not sure if this is what you're after though.
Actions
6. Re: accessing docker image based JBoss Transaction Manager as a service from a Weld/CDI based docker image

peterfry Jun 23, 2015 1:18 PM (in response to marklittle)

Yes that will work if the the technology stack being used is Wildfly / Java EE.

So with WF-Swarm based microservices it is quite straightforward. If there is another microservice not based on WF-Swarm is where things break down.

I'll reply to gytis separately with the RTS based approach.
Actions
7. Re: accessing docker image based JBoss Transaction Manager as a service from a Weld/CDI based docker image

peterfry Jun 23, 2015 1:38 PM (in response to gytis)

I've seen this forum post:

REST-AT and Container-Managed Transactions

Quoting from this mmusgrov

We don't currently support automatically starting REST-AT transactions. We decided against that because the service that creates coordinators (aka begin a transaction) could reside anywhere on the network. - See more at: https://developer.jboss.org/thread/259022#sthash.VnbKQDki.dpuf

Granted anywhere on the network does cause problems, where things might become simpler is if the services are known by kubernetes, then service discovery can be mediated via kubernetes.

Then taking some inspiration from the fabric8 service injection work automatic REST-AT transaction might be possible:

CDI | Fabric8 Documentation

Granted, there is an awful lot of detail missing from my suggestion.
Actions
8. Re: accessing docker image based JBoss Transaction Manager as a service from a Weld/CDI based docker image

marklittle Jun 23, 2015 7:40 PM (in response to peterfry)

The biggest problem is where the transaction log resides. Not a rocket-scientist problem, i.e., can be fixed. But given Kube requires immutable containers it means that we need to be sure the log is maintained away from the docker image that is the transaction manager.
Actions
9. Re: accessing docker image based JBoss Transaction Manager as a service from a Weld/CDI based docker image

gytis Jun 24, 2015 4:58 AM (in response to peterfry)

Peter,

I've just had a discussion with mmusgrov, and we think that we could implement automatic start of the REST-AT, if that feature is requested.
I don't know much about kubernetes, but what I suggest is to have a configurable field in standalone.xml with the URL of the transaction manager. By default it would be a locally running one, but it could be changed to the remote endpoint. Pretty much the same thing as is in XTS.
Would this work for your case?
Actions
10. Re: accessing docker image based JBoss Transaction Manager as a service from a Weld/CDI based docker image

peterfry Jul 1, 2015 4:46 PM (in response to gytis)

Gytis,

Yes that sounds like it would definitely make using transactions for REST services even easier:

If I understand http://jbossts.blogspot.de/2013/04/simplified-xts-context-propagation.html correctly and applying it to rts then:

1) Invoke a rest endpoint hosted in a micro-service
2) the endpoint implementation establishes a JTA context via @Transactional
3) within this transaciton context some calls are made to REST endpoints hosted in a different micro-service (in a different container) but which support REST-AT.
4) the RTS subsystem present in the first micro-service would propagate the JTA context via the bridging mechanism to the second microservice.

In the docker/kube world the bridge could lookup in kube the transaction service URL.

Peter.
Actions
11. Re: accessing docker image based JBoss Transaction Manager as a service from a Weld/CDI based docker image

peterfry Jul 1, 2015 4:17 PM (in response to marklittle)

So in Openshift v3 that could be a persistent storage mount ?

Peter.
Actions
12. Re: accessing docker image based JBoss Transaction Manager as a service from a Weld/CDI based docker image

peterfry Jul 1, 2015 5:15 PM (in response to gytis)

Gytis,

Looking at the rts bridge code it appears to be almost portable (I saw a dependency on RestEasy).

If it is portable then with an externalized transaction service it could/should be possible to use it in a Apache CXF REST endpoint?

i.e. I'm imagining the use case of a coordinating service hosted in a Wildfly instance which establishes a REST-AT transaction context which propgates to both a Wildfly hosted REST endpoint and a Apache CXF REST endpoint hosted in a different container. The transaction service being external to all three.

Peter.
Actions
13. Re: accessing docker image based JBoss Transaction Manager as a service from a Weld/CDI based docker image

gytis Jul 6, 2015 12:28 PM (in response to peterfry)

That article is talking about different improvement, which simplified WS-AT/WS-BA handlers configuration.

But your explanation of the workflow is correct. We would have to implement bridging from JTA to REST-AT. This will allow you to start the transaction with @Transactional in one microservice and then invoke rest endpoint in another. There is a JIRA for this, but nobody worked on it since it wasn't requested up to now [JBTM-1109] JTA -> REST-AT Bridge - JBoss Issue Tracker. I'll have to speak with my teammates if/when we can add it to our schedule.
Actions
14. Re: accessing docker image based JBoss Transaction Manager as a service from a Weld/CDI based docker image

gytis Jul 6, 2015 12:38 PM (in response to peterfry)

We do test our REST-AT transaction manager in standalone environment. However, I have never tried to run the bridge outside of WildFly. I'm guessing that it would be possible, if all the libraries would be available, but some of them are not as straightforward. In any case, this sounds as an interesting thing to try.
Actions

Go to original post