ExtremeTransactions 5.0.109

ExtremeTransactions 5.0.109 release notes

Feature200360

Subscription files are now required for production use

Description

We now require customers to install subscription files for production use, similar to what we do in 6.0.

Technical details

We've had some bad experiences with subscriptions purchased via resellers / intermediaries, that were first used by a development team, then moved onto other teams in production without us being able to keep track. This has lead to unpleasant experiences for both our customers and ourselves.

For more details, see this documentation page.

Changes impacting client API

You need to install 2 files as explained on the documentation page mentioned above. Note: development or testing use does not need subscription files.

Feature201309

Detect vulnerable dependencies on classpath

Description

We now help you find out about known vulnerable maven dependencies that your application is using.

Technical details

With current hacker efforts moving more and more into the application stack via vulnerable open source dependencies, we notice customers are getting worried (or facing audits of their applications). Log4j, anyone?

Our approach has been two-fold:

• We avoid 3rd party dependencies so you can't pull them in by accident, and
• We now also detect known vulnerable 3rd party maven dependencies on your application's classpath

Starting in the near future, expect more and more "security updates" in that respect.

Changes impacting client API

None.

Bug197240

Allow spring.jta properties in Spring Boot starter

Severity:	4
Affected version(s):	5.0.x

Description

Any spring.jta properties in Spring Boot should now be taken into account.

Technical details

After the Spring Boot team contributed the source code for their Atomikos starter we thought it was safer to ignore any properties with the "legacy" prefix spring.jta.atomikos.properties (in your application.properties file for Spring Boot).

This has proven to confuse users, so we now take such spring.jta properties into account.

Changes impacting client API

Any spring.jta properties in Spring Boot should now be taken into account.

Bug197505

Avoid that defaults in the Spring Boot starter override jta.properties

Severity:	4
Affected version(s):	5.0.x

Description

You can now count on the property values from jta.properties to be taken into account even with Spring Boot.

Technical details

The Atomikos JTA properties implementation in our Spring Boot starter would define default values for many properties, meaning that their value specified jta.properties would not be taken into account. This has now been fixed.

Changes impacting client API

Your properties specified in jta.properties should now work.

Bug197362

Clarify message if rest port not set in client

Severity:	1/2/3/4
Affected version(s):	5.0.x

Description

You can now count on a better error message when the AtomikosRestPort URL is not set (for transactions across remoting calls).

Technical details

When the AtomikosRestPort URL was not set, the client template would report a misleading message saying that there is no transaction for the thread. Instead, the root cause is a URL that is missing - so we fixed that for you.

Changes impacting client API

None.

Bug197506

Support diamond case architectures for readOnly remoting

Severity:	4
Affected version(s):	5.0.x

Description

You can now use transitive readOnly remoting transactions in all cases.

Technical details

As outlined in this GitHub issue there was a problem with readOnly invocations when:

• the same shared service was called over different paths, and
• all invocations were readOnly

This is known as a "diamond case" because the invocation diagram looks like a diamond.

This issue has been fixed in the following way: our product will now avoid the readOnly optimisation in this specific scenario. This is still correct, at a minor performance overhead in the exotic cases where this does happen.

Changes impacting client API

None.

Bug197253

Suspend/resume should not change local sibling count

Severity:	2
Affected version(s):	5.0.x

Description

You can now use @RequiresNew with imported transactions.

Technical details

As explained in this GitHub issue, there were problems when a remote transaction was imported and then subsequently called local logic that was marked with @RequiresNew. As required by the specification of @RequiresNew, this would suspend any active transaction - and resume it later.

Our code had a side effect of suspend/resume that changed the local sibling count.

Sibling counts help detect orphaned invocations (and their transactional updates to persistent storage) that arise out of lost replies. For instance, consider this scenario with services A and B:

1. A starts a transaction.
2. A calls B as part of that transaction.
3. B does work and returns a result.
4. A does not receive the result due to a network timeout (so B now has an orphaned invocation).
5. A tries again, so B performs the changes again and returns a new result (in the same transaction).
6. A commits the transaction thinking it only updated B once.
7. B commits the same transaction with two sets of updates.

This risk here is the different views of A and B regarding the scope of the transaction: A thinks it commits one update to B, whereas B commits two different updates. This can be a problem for data consistency, so we avoid this by keeping sibling counts at B and A. A constructs its sibling count picture with each result it actually receives with its replies from A. Before commit, A passes on the "count" it has for invocations at B, and if B finds that there is no match then it refuses to commit.

This would avoid the problem outlined above, because in step 4 service A will miss a count, so in step 6 service A will pass a count of 1 for service B, whereas B will see 2 and refuses the commit process.

In short, sibling counts have their purpose. However due to a bug, this was affected by a suspend/resume at service B (when it has @RequiresNew logic inside).

Changes impacting client API

You should now be able to configure @RequiresNew on any service that needs it.

Bug211208

Avoid init-ing connection factory twice or more on Tomcat JNDI lookups

Severity:	4
Affected version(s):	5.0.x

Description

You should now be able to perform any number of JNDI lookups in Tomcat without getting warnings about the resource already existing with the same name.

Technical details

During JNDI lookups, Tomcat applications would sometimes get warnings like below due to a race condition. This has been fixed.

WARNING: Cannot initialize AtomikosConnectionFactoryBean
java.lang.IllegalStateException: Another resource already exists with name XAConnectionFactory - pick a different name
      at com.atomikos.icatch.config.Configuration.addResource(Configuration.java:241)
      at com.atomikos.jms.AtomikosConnectionFactoryBean.doInit(AtomikosConnectionFactoryBean.java:440)
      at com.atomikos.jms.AtomikosConnectionFactoryBean.init(AtomikosConnectionFactoryBean.java:354)
      at com.atomikos.jms.AtomikosConnectionFactoryBean.createConnection(AtomikosConnectionFactoryBean.java:620)

Changes impacting client API

None.

About Severity

The severity levels we use are defined in our support terms and conditions.