Release notes for the 4.0.71 release…

172566: Improved support for maxLifetime enforcement

Even though we had a maxLifetime for connections in the pool (to avoid firewall issues), this was only applied to connections that were available at the exact moment when the pool's maintenance thread was doing the checking. This has now been improved: even if a connection is not available at the time of checking (i.e., in use by the application) it will to be reused again after its maxLifetime has passed.

172524: Race condition in ConnectionPoolWithConcurrentValidation on destroy of pooled connection

The new pool had a race condition between the application threads and the pool's maintenance thread, as follows:

The maintenance thread would do the following - without the synchronisation of our older pool:

  1. Loop over all connections to check which ones are available.
  2. Close (destroy) any such available connections that it deemed no longer needed.

In parallel, the application threads would be getting connections from the pool. This means between steps 1 and 2 of the maintenance thread, it could happen that a connection was gotten from the pool and subsequently destroyed by the maintenance thread.

This has now been fixed.

172571: CleanupPendingTransactionContextFilter: improve behaviour and enable toggling via property

Our servlet filter takes care of cleaning up any pending transaction context for applications that don't cleanly end the transaction association of the calling thread. Previously, this happened only when the thread was reused for a later request (via thread pooling in the servlet container). This can take time, and the resulting warnings are hard to link back to the original request.

This has been improved by making the cleanup also happen directly after each request (rather than waiting until a next request comes in).

Also, per customer request we've made it possible to "disable" this filtering behaviour if required, by setting the property

This can happen either in the file, or via a System (JVM) property. This way, you can leave the filter in your web application's web.xml file - which should make life a bit easier on the operations people.

169220: Specify a timeout for the testQuery

We now reuse the borrowConnectionTimeout value as the timeout for the testQuery - so testQueries don't block indefinitely and the pool's availability is improved.

172247: AtomikosDataSourceBean: don't log testQuery warning for concurrentConnectionValidation mode

Historically, a testQuery would generate warnings regarding performance. With the new concurrent validation pool, this is of course no longer required.

Available to customers only. Want to become a customer?

Send me a quote

Contact Us

Atomikos Corporate Headquarters
Hoveniersstraat, 39/1, 2800
Mechelen, Belgium

T +3215613055

Subscribe to our newsletter

Never miss an update

Copyright 2020 Atomikos BVBA | Our Privacy Policy
By using this site you agree to our cookies. More info. That's Fine