Fixed a bug where retry of a one-phase commit would lead to needless heuristic hazard warnings (and pool congestion). It does not make sense to retry 1-phase commit because, for instance, a typical failure could be cause by a transaction timeout in the resource.
When a transaction timed out we used to hint at different options / causes in the warning. This has been improved to be accurate now.
We've increased the frequency with which pending statements are closed - to lower memory consumption.
Fixed a race condition where non-xa connections could be borrowed by 2 concurrent threads under high load, leading to errors in the log like this:
java.sql.SQLException: Can't call commit when autocommit=trueFor our Tomcat integration we now also log a bit more: before and after each request.
In module transactions-spring, we have added two new filters:
These can be used to cleanup pending Spring state. Normally this is done by Spring's JtaTransactionManager, but in case of pending transactions on a Tomcat request thread, the Spring transaction cleanup may not happen. In those cases, you need these filters or you will see weird warnings like these:
WARNING: Attempt to use connection after it was closed.Adding these filters should prevent that.
We've refined exception handling for the rare case where flushing a commit record to the log fails.
Although unlikely, reaping would attempt to mark the connection as reusable before it was destroyed in the pool. In theory this could give race conditions so we have improved that.
We used to log two times the same warning in some exceptional cases, this has now been improved.
This kind of exception can happen after a reap and does not have to lead to useless warnings, so we treat this separately now.
While growPool was executing createPooledConnection, it had a lock on the entire pool. In case of network timeouts, this can take a long time and this forbids other threads from getting a connection. We've fixed this.
Due to recent community changes that were merged in the stable branch, we accidentally omitted deleting a connection from the pool after it was reaped. This is now fixed.
This listener class for Tomcat integration used to shutdown the transaction core on STOP events. Due to (lack of) ordering during such STOP lifecycle event, there may still be active web applications when this is called. As a result, any remaining message listeners will start giving warnings that the core has already been shutdown, along with its JMS resources.
This has been fixed, at the expense of a different (but less intrusive) warning like this one:The web application [/...] appears to have started a thread named [Atomikos:5] but has failed to stop it. This is very likely to create a memory leak.
This is due to the limited knowledge the Tomcat core has about Atomikos threads. It can be ignored, there is no memory leak in this case.
It does not make sense to have connections in use for more than maxLifetime, so now we reap in that case. This is to avoid pool exhaustion if connections are held and blocked for a long time.
It is now possible to also use the new pools with JMS.
For safety reasons, we now add the recovery domain name to the transaction propagation - so we avoid transactions across recovery domains.
Heuristics are the responsibility of the recovery module in the background, so it is not necessary to log errors in the OLTP module.
Experience has shown that failures during prepare can result in confusing exception messages. We've tried to improve this even more.
Fixed a bug where transactions were not cleaned up after timeout - thereby possibly causing a memory leak in the core.
Added (trace-level) logging to show the number of open contexts for a pooled connection when the pool checks its availability.
We no longer log a warning when trying to create a new connection with a custom userName and password. This is because some frameworks depend on this method, which causes a lot of noise in the logs. Instead, we now log this in debug level.
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.
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:
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.
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 propertycom.atomikos.icatch.http.filter_requests=false
This can happen either in the jta.properties 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.
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.
Historically, a testQuery would generate warnings regarding performance. With the new concurrent validation pool, this is of course no longer required.
In addition to REST support, we've added a new incarnation of our SOAP web service transaction support. Once more you can make transactions span web services, but this time it's not according to the inefficiencies of a bloated standard specification. Rather, it's the way we think it should be - no compromises!
We now log init calls as INFO so it is easier to find mistakes in the configuration.
In this release we merely fixed the REST demos (which were broken in the last few releases).
When loading from different jars, non-public interfaces in the vendor's drivers could sometimes lead to proxy creation failures for the JMS session. This was notably the case for Tibco EMS. We now catch the error and create a minimal working proxy instead.
Some of the REST demos don't work in this release - this will be fixed in an upcoming release. This will only affect development projects that are testing REST transactions.
You can now set the interval after which JDBC connection validation should be repeated, so users can have an application-specific impact on performance.
Similar to JMS, we added the capability to specify the XADataSource as a JNDI reference in Tomcat.
Similar to JDBC, we now also allow specifying the XA vendor settings via the class name (instead of only the JNDI reference).
Another incremental performance optimisation to maximise performance.
Some of the REST demos don't work in this release - this will be fixed in an upcoming release. This will only affect development projects that are testing REST transactions.
We've eliminated some logging contention points by replacing synchronized blocks with reentrant locks (shared versus exclusive).
We incorrectly passed a milliseconds value for the JTA timeout - which expects a seconds value. This would lead to numerous log warnings like: "Attempt to create a transaction with a timeout that exceeds maximum - truncating to xxx". This has now been fixed.
Creating a subtransaction did not set the correct root, which made it hard for different subtransactions to share locks.
We've added a special header to facilitate lock sharing among related transactions across different incoming REST calls.
We've added the root transaction to the propagation headers to facilitate lock sharing among related transactions across different incoming REST calls.
Failed remote calls can now safely be retried without risking duplicate transactions at the remote end.
This demo has now been fixed.
This demo has now been fixed.
This demo has now been fixed.
While testing this release, we've noticed that some of the REST demos no longer work - this will be fixed for the next release. This will only affect development projects that are testing REST transactions.
Refactored the connection pool: the testQuery is now executed outside of a synchronised block for better performance.
In-line with INFO logging policies, shutdown methods now log an INFO message.
The testQuery used to be in a synchronised block, now this is no longer the case thanks to a new pool implementation. This is a port of fix 94285 (commercial branch) to the community.
A call to borrowConnection() used to become blocked due to one thread entering canBeRecycledForCallingThread() it that then waited for the SessionHandleState lock - if in use by another connection at the same time. We fixed this by making canBeRecycledForCallingThread() returning false without locking.
We now create the JNDI reference only after the pool has been created - it does not make sense to expose a faulty pool.
We've clarified the error reporting to make it clearer what happened, and avoid confusion.
We've improved the logging for timeouts - to avoid confusion.
We used to refresh to XAResource on connectivity issues. Refreshing made little sense in case of 1-phase commit because there is no prepared transaction XID in the datasource, meaning a different connection would probably not know about it.
This is one of the best performance improvements we ever made: we now ensure that the (new) pool does not impact performance when setting a testQuery. This makes our pools about as fast as non-JTA/XA pools, meaning reliability comes without the performance cost for your application! (Check our commercial offerings if you want even more…)
Fixed a bug in the new recovery where checkpoints would purge too much.
Fixed a synchronisation bug that would show up under high loads and would lead to incomplete checkpoints.
Fixed an issue with missing equals/hashCode implementations that would break 2-phase commit in certain conditions.
We've added a new pool that makes the testQuery more efficient. Now, we went even further and avoid the testQuery overhead on connection recycling. This mainly makes it faster for transactions that do multiple SQL statements in the same transaction.
Thread reuse in Tomcat used to inherit the transaction timeout set by a previous request (if any). This could be confusing so we now reset the transaction timeout between requests.
The default checkpoint interval used to be suboptimal for performance - our commercial distribution is now tuned in this respect.
Added built-in support and examples for the Spring REST framework.
Added built-in support and examples for the Spring HttpInvoker remoting mechanism.
Clarified with missing instructions for seamless testing of the demo.
Improved the new recovery to interpret 0 as unlimited, and we now log a warning if this happens with XA.
We've improved our transactions-jndi-provider module: if you use our com.atomikos.jndi.AtomikosContextFactory as the initial context factory then you can delegate unbound lookups to a third-party provider specified as "env."-prefixed properties in the jndi.properties file.
For instance: env.java.naming.factory.initial = … would set the third-party context implementation to delegate to.
This class used to take a separate parameter on the command line - thereby hiding the value specified in the jta.properties file. This has been fixed.
Fixed a bug in the demo: the inventory should not return "Accepted" status for updates.
It should not be allowed to have a commit when some calls are still pending - since the commit scope will not be well-defined in that case. We now have a check for that.
Fixed a bug where the timeout was confused with the expiration date/time in the request header of incoming requests. This would lead to excessive timeouts.
For extra safety, we've improved the filter to omit any headers in case of server-side rollback. This way, the client transaction manager cannot get confused and still attempt commit.
Because of the previous case (166211), the client should not commit a transaction where there is no participant for the remote work. Otherwise, the transaction commit scope would be undefined.
We've improved the examples and added support for both JAX-RS and Spring REST/MVC - so you can build microservices with your favourite toolbox.
We've improved logging in the REST module - so it's easier to see what happens.
It seems we did not log this new property value on init yet. This has now been fixed.
Applications that embed an Atomikos transaction manager can now transparently make JTA transactions span outgoing REST calls.
We now have a plain JavaScript client to show how non-Java clients can still use our REST transactions.
Improved exception handling: occasionally, would would swallow exceptions (shame on us!).
The testQuery used to execute with an undefined autoCommit mode - so if the connection had autoCommit disabled, the testQuery would start a new (local) transaction context that conflicts with XA.
To facilitate finding connection leaks, we now start collecting and logging stack traces of getConnection() calls after the first reap.
From now on, all local JTA transactions can be exported / extended over REST - so outgoing REST calls can become part of the commit scope.
Fixed a bug where recovery of an expired committing Xid failed silently. As a result, expired committing entries would stay in the transaction log because this would fail on every recovery scan. This has now been fixed.
We now save process id of the running process, so wrong restarts of the monitoring tools can show a meaningful error message. Currently available for unix-type platforms only.
We improved the monitoring utilities to make it easier to correlate XIDs in the transaction log (JSON format) with XIDs in the diagnostic logs. Due to different formatting rules, this was difficult.
See the examples-jta-rest sample for a working demo…
Fixed a bug where local sub transactions would not be recovered.
Fixed a bug where imported transactions would sometimes not get the right coordinatorId for recovery.
Improved the import mechanism for microservice transactions to ensure correct recovery in all cases.
Added a log warning when there an out-of-memory is approaching.
Improved mixed recovery where the Main.LogCloud would interfere with XA recovery.
We now show the Main.LogCloud in the examples with RMI.
JMX is now also supported for non-xa datasource instances.
Our datasources now have an optional failOnInitIfDatabaseDown setting, and the AtomikosConnectionFactoryBean has a similar failOnInitIfBrokerDown option - both of which will make the init fail if the backed resource is not available at the time of init.
We've added support for managing JMX beans in our Spring integration - so you don't have to.
Fixed a bug where occasional pending in doubt transactions could not be cleaned up.
We've added a dedicated TimeoutException (subclass of RollbackException) so applications can catch this specific exception to be informed about timeouts.
Applications can now register event listeners to be informed about PooledConnectionBorrowedEvent and PooledConnectionTerminatedEvent instances - so the application can roll its own monitoring if desired.
Recovery now logs warnings so it's hard to miss important recovery actions.
We've added a demo config also to the regular (non-Spring-based) Tomcat examples.
We fixed a design flaw where the new recovery could suffer from interference of concurrent recovery / rollback. Our fix has been proven mathematically correct so we're pretty convinced this makes things bullet-proof from now on.
We've improved supportsTmJoin functionality to be consistent with the other AtomikosDataSourceBean properties.
You can now construct an instance with custom init properties that will be taken into account.
We've widened the impact of supportsTmJoin=false to avoid all XA joins completely - so you can work around problems with XAResource implementations that lack decent support for this.
Fixed log formatting for stack traces on timeout - so that concurrent threads don't log in between.
Improved logging of what really should be a warning, not a debug entry.
It is now possible to delegate JNDI lookup of JDBC/JMS resources to 3rd party JNDI providers - all from within the Tomcat JNDI space.
We've improved the hazelcast integration to allow for pure client/server deployments.
We now publish the participating resources as part of these events so your integration tests can verify the scope of a transaction.
Fixed a race condition where recovery could interfere with OLTP commits.
Improved logging and log level checks a bit, so INFO logging is less verbose.
We now avoid logging rollback exceptions as ERROR when the only possible in the participant / resource is rollback.
The comparison code for enlisting Hazelcast instances has been improved to provide more flexibility for custom wrapper classes.
Improved logging and log level checks a bit, so INFO logging is less verbose.
The examples were a bit sloppy in cleaning up connections, which has been fixed.
The filter was missing in the example, it's been added now.
The README file has been updated to mention the latest greatest examples.
We've added the source code jars so evaluators can easily click-through in their IDE to inspect source code.
There was a cosmetic logging glitch that slipped into the context filter and would cause it log needless warnings. Fixed!
Improved existing fix with respect to logging frequency: we now only log stack traces once, instead of on every timer alert after a timeout happens. This reduces logging volumes quite a bit.
Init-ing datasources or connection factories with an unavailable backend would lead to startup failures in some cases; this has now been fixed.
For those who want do do their own "transaction management" but delegate recovery to Atomikos: we've opened up the LogCloud with a REST API. See the relevant examples for more information.
java -jar transactions-tcc-rest.jar 8080 (or replace 8080 by whatever port you want to use).
The new recovery module logged XIDs in a different format than the OLTP logic did, which was confusing to read. We've now aligned them.
Timeout / setRollbackOnly of an active transaction now also shows the stack trace(s) of any threads that were active in the transaction - so it is easier to find out what is causing the timeout.
Improved the warning message by also suggesting what can be done to avoid it.
Added useful extra logging to show what is going on.
The LogCloud service now displays the RMI address on which it is available - so clients are easier to configure.
We've improved the way that transaction identifiers are generated so the probability of collisions in cluster deployments is minimised.
Our Spring integration module now also logs what it is doing, in what order.
It is now also possible to include the UserTransactionServiceImp with our built-in Spring integration - so you can tune the init properties inside your Spring config.
We've improved a prior fix in the 4.0.x recovery mechanism so we can avoid that stale connections stay around during recovery.
Improved handling of erroneous connections for recovery: in some configurations the connection can be broken, and needsRefresh does not seem to detect this - resulting in repeated recovery errors on each scan. We now refresh the connection automatically after any recovery error.
Heuristic log entries are now automatically discarded when all participant entries are either terminated or heuristic. Upon discarding, we generate an event to allow for monitoring in external tools.
Improved the housekeeping of the log for parent/subtransaction situations.
Subtransactions could be pending in the INDOUBT state while the parent transaction was logged as COMMITTING. The only correct recovery for the sub transaction is to commit, so getCommittingParticipants() should return the participants of the subtx.
This exotic optional feature was not safe with the new recovery and also not compatible with the LogCloud.
We now use the uniqueResourceName of each resource to improve the housekeeping of pending log records.
Fixed an issue where sub transaction rollback was possible during recovery, when the parent did commit.
Logging for sub transactions was incomplete and did not include the parent transaction's id. This is now fixed.
Improved recovery for subtransactions with problematic parent transactions.
Pending log entries in the ABORTING state will now also be cleaned up during recovery.
Non-recoverable states like ABORTING (created during recovery) don't have to be logged because they are reproducible on the next recovery scan. We now avoid writing such entries.
We now also correctly recover and commit IN_DOUBT participant entries when the overall outcome is some form of heuristic.
We found and fixed a race condition where synchronisation was lacking.
For operational monitoring, we now generate a warning event when a resource may have been removed from the configuration while it still had pending transactions in the recovery logs.
You can now also use Hazelcast with the LogCLoud.
Sensitive connector properties are now encrypted over the wire and on disk.
Hazelcast is now also supported as a LogCloud resource.
The new property com.atomikos.icatch.default_max_wait_time_on_shutdown allows configuring the max number if milliseconds that shutdown will wait when in no-force mode.
Added a new example with Hibernate 5.
A timeout of an active transaction will add a RollbackOnlyParticipant to make prepare fail. However, later on in the logs this shows up as a NO vote cryptic error that people didn't understand. This has now been improved.
javax.transaction.RollbackException: Error in committing: Existing entry: ABORTING incompatible with new entry: COMMITTING - recovery will clean up in the background
We've changed this to point out that intermediate recovery is responsible for this situation.
We've loosened state transitions a bit to avoid needless warnings in the logs.
Disabled retrying confirmation when recovery is disabled - after all, retrying confirmation is a form of recovery.
A bit more diagnostic logging proved useful when things go wrong…
We now tolerate participant service without OPTIONS method so confirmation can still proceed.
The Tomcat JNDI factories specify an internal 'singleton' property that generates warnings when set on Atomikos datasources or connection factories. This property is now being ignored to avoid needless warnings.
We recently switched to the new JAX-RS 2.0 client API, thereby giving up checked exceptions on client calls (in favour of response codes that need to be checked explicitly). This caused us to miss on some HTTP error codes, which has now been corrected.
For those who need parallel processing in their transactional applications, we've now added an explicit example of that. See examples-jta-multithreaded in the examples download.
We've optimised the confirmation process to check availability of all participants before attempting to confirm, in order to avoid needless 409 conflicting outcomes.
The existing init parameter com.atomikos.icatch.enable_logging has a new optional value to disable recovery altogether:
com.atomikos.icatch.enable_logging=none com.atomikos.icatch.oltp_max_retries=0
This will install a NullRepository for logging purposes, so the transaction logs will always appear attempt and recovery will not do anything. The second parameter is needed to avoid OLTP retries ("recovery") of heuristic transactions.
We've done various little changes to make the example programs and/or the free trial experience better or more ergonomic. There were no known bug reports so we don't bother mentioning each individual case here.
JAX-RS 2.0 has a new standard client API so our code now works (in theory) with any compliant implementation.
It seems that we forgot to activate TCC recovery in prior releases - this is now fixed.
We now log a pointer to our documentation when there are heuristic errors, so it's easier for operations people to know what to do.
Fixed a demo that would no longer run.
Fixed a demo that would no longer run.
For transactions with only one participant there is no longer any forced disk writing on 1-phase commit.
The demo / sample programs no longer display the following message:
Thanks for using Atomikos! Register at http://www.atomikos.com/Main/RegisterYourDownload to disable this message and receive FREE tips & advice.
The new API contained a few nasty cyclic dependencies that we've removed - while this release is still in beta.
Logging now supports Log4j2 when found in the classpath.
The new event mechanism now also works for the new recovery.
There is no need to justify a builder - just use the equivalent factory class in the same package…
The existing error message was a bit unclear - this has now been fixed.
No comment needed here…
Since this is now open source, there is no need for license files any more so we've removed them.
The immediate benefit of the redesigned recovery and logging mechanism is that customers can now configure an external logging and recovery service - allowing you to dynamically add / remove application processing nodes without impacting recovery. For more details, see Main.LogCloud.
We've completely redefined how logging and recovery work. As an added bonus, this new design also simplifies the regular transaction processing code (recovery is no longer a concern) and should reduce memory usage during normal operation - while also making heuristic cases less of a burden.
The .epoch file mechanism is no longer used - which in turn improves cloud friendliness of our product.The logs are now in a human-readable text format for optimal comfort during administration.
This functionality seemed a bit exotic to carry on in our codebase, so we've optimistically removed it for now. Should there be compelling use cases to add them again, we will do so at a later time. Most of our user base adheres to the JTA/JDBC/JMS API and will not be affected at all by this removal.
See Documentation.JtaProperties for specific changes as of 4.x.
JMX support is now divided across 2 modules; one transactions-jmx (core) module and also transactions-jmx-jta for specifics relevant to JTA.
Make sure to shut down in no-force mode first, and delete the logs of your old version (which is safe after no-force shutdown).
If you don't use the transactions-api directly then your application should work fine (still, be sure to check our new init property lookup!). If you do use our transactions-api then you might want to check the following:Configuration class was moved to package com.atomikos.icatch.config.
UserTransactionService no longer has the init(TSInitInfo) method: initialisation now takes either no arguments, or a java.util.Properties argument.
Various details are explained below… Enjoy!
For compatibility with third-party code expectations we now allow methods like hashCode to be called on closed connection handles.
Contributed by Christoph Schmidt-Casdorf, Deutsche Post.
The setTransactionTimeout is now thread-local so threads do not interfere if they set this property.
You can now prevent nested transactions from being started - see Documentation.JtaProperties for details.
We have refined and improved the way we log: see Documentation.ConfiguringTheLogs for details.`
Exceptions now report the expected file location so debugging your configuration is easier.
For our new logging policies we need trace and this is only available in version 1.4 of SLF4J.
The TransactionControl interface has been removed from our API and its remaining functionality has been merged into the CompositeTransaction interface.
The Map is cleaner at API level (not a JDK implementation class).
Added a contributed improvement for dynamically registered XAResource instances so we avoid race conditions under high load.
We now avoid serialisation with our brand-new recovery implementation.
OLTP logging and restart/crash recovery logic are now separated, which simplifies the transaction state handlers and puts us on the road to improved compatibility with cloud deployments.
Shutdown used to be binary: either you waited for active transactions to finish, or not. We've now added an option of specifying a timeout in milliseconds. The system will wait for active transactions to finish within the specified delay, and resort to forced shutdown after that.
We changed this in an attempt to make resource names more unique. A more profound solution will be available in a later release, when we improve dynamic resource registration.
This feature is no longer needed in our modernised code base so we have removed it.
The build now works on/with the latest JDK versions.
All built-in primitive types are now supported.
No comment needed on this one - it is an internal issue.
We've added one big zip file for all demos - this is simpler to handle for everybody.
The OSGi examples are now included again. Previously, they were excluded because the build used to fail on them.
Our coordinator service implementation did not properly set the Accept header when confirming a participant service. This has been fixed.
The following methods are sure to be allowed after close: rollback, setRollbackOnly, suspend, resume.
Documented the event mechanism (in the PDF guide covering the API).
It is now possible to quickly launch a coordinator server from the TCC demos so you can easily test your own participant services for compliance.
See ExtremeTransactions3dot9dot3 for details.
Added runnable example to demonstrate Hibernate 4 integration.
The log level has been increased to avoid losing time chasing errors that happen during beforeCompletion and prevent committing the transaction.
We now support hibernate 4 in an easy way, as demonstrated by the corresponding new examples.
We now avoid writing .epoch files for increased flexibility and usability.
We no longer need Swing libraries: these have long been replaced by JMX support.
Disabling transaction logging now works again.
This setting got ignored in the 3.9 release, meaning there was no way to turn logging off - this has now been fixed.
For now, this module is no longer compatible with the new logging/recovery and has been removed. Later on, we'll consider the equivalent for the new logging mechanism.
Added a new constructor that accepts the ConfigProperties as parameter. This allows reuse of config parameters that are looked up by the core startup.