Atomikos - Unique resource names

Question

We have a Java micro service project using spring boot and want to know if the following properties must be unique across the servers in the cluster as per the blog post https://fogbugz.atomikos.com/default81d0.html?community.6.2225.7

App is based on

Spring Boot - 1.5.12.RELEASE
Spring - 4.3.16.RELEASE
Jersey - 2.25.1
Active MQ - 5.14.5
Atomikos - 3.9.3
RedHat Java - 1.8.0_191

The functionality includes JDBC, JPA and JMS

Sample Server names: node1, node2, node3

If the properties below are the same on all servers like shown below, then I believe it will cause issues with transaction recovery and other possible XID issues, correct?

com.atomikos.icatch.tm_unique_name = myapp-tm-node
spring.jta.atomikos.datasource.unique-resource-name = myapp-db-node
spring.jta.atomikos.connectionfactory.unique-resource-name = myapp-jms-node

So technically the values of the above properties should be unique on each node like shown below, correct?

com.atomikos.icatch.tm_unique_name = myapp-tm-node1
spring.jta.atomikos.datasource.unique-resource-name = myapp-db-node1
spring.jta.atomikos.connectionfactory.unique-resource-name = myapp-jms-node1

Likewise the property values ending with "node2" and "node3" on the other two servers

Are you using Atomikos internal in your Spring Boot Application or do you have an Atomikos instance deployed separately? — Simon Martinelli, Jun 12 '20 at 06:39
The you don't have to care about the name because you have one Transaction Manger per node. — Simon Martinelli, Jun 12 '20 at 15:12
That is good to know.. If there are multiple Spring Boot micro service applications using Atomikos on each node, then that means the three property values above for those apps should be unique, correct? — Krishna, Jun 12 '20 at 15:22
Exactly. If the Atomikos transaction manager is shared every party that uses it needs a unique id — Simon Martinelli, Jun 12 '20 at 15:23
If you don't mind I will add this as the answer so you could accept it — Simon Martinelli, Jun 12 '20 at 15:38

score 1 · Answer 1 · answered Jun 27 '20 at 10:20

The com.atomikos.icatch.tm_unique_name must be unique for each JVM you start, by default it is based on the IP address. Exception: if you have an elastic cloud application based on the LogCloud then there is one single shared name for the whole "recovery domain" (i.e., the name of your elastic clustered application).

The uniqueResourceName must be unique in each JVM. It can be shared across JVMs - which is typically the case in a clustered application.

Guy

score 0 · Accepted Answer · answered Jun 12 '20 at 15:39

0

The you don't have to care about the name because you have one Transaction Manger per node.

Only if the Atomikos transaction manager is shared every party that uses it needs a unique id.

answered Jun 12 '20 at 15:39

Simon Martinelli

34,053
5
48
82

Andrew Harrison · Answer 3 · 2021-10-15T10:51:35.737

This is something I came across very recently.

The short answer is: yes, the unique parts need to be unique per JVM.

The reasoning: In my instance, the issue was only experienced under heavy load and was particularly difficult to reproduce. Then it was noted that the XID (Transaction ID) being generated was based on the number of nanoseconds since EPOC, prefixed by the tm_unique_name. We had 4 instances of the application server, each using the same tm_unique_name. Under heavy load, we would see very occasional failures where the Transaction was no longer valid.
It comes to reason that more than one instance had created transactions that had been in-flight at the time with the same XID due to the time-based element. When one had been committed on the database, the state of the other(s) with the same XID became undetermined.

The solution: Make the unique values unique per JVM.

I hope this helps someone as it took a while to come to this conclusion.

Atomikos - Unique resource names

3 Answers3