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.Try-Confirm/Cancel) so it becomes accessible to everyone. We (and many others who gave us feedback) are convinced that TCC is the ultimate transaction model for REST. We would be honoured if you (re)used our implementation for your needs, and please let us know if you see any ways of improving it. In case you wonder if we are giving up on monetising TCC: we're not - rather, we intend to provide commercial value-add modules for various cloud deployments that are not provided by the pure open source distribution.
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.ServiceLoader mechanism. The TSListener interface has been refactored and renamed to TransactionServicePlugin and it has become the main plugin interface for this architecture. In the same style, we've added core event notifications to our API, so plugins and external modules can be notified about significant transaction events. This makes it possible to build monitoring utilities on top of our product - both by the community and commercially by us. forum post):
- defaults are loaded from the classpath
- any overrides from transactions.properties (if found in the classpath) are applied
- any overrides from jta.properties (if found in the classpath) are applied
- any overrides in a properties file specified by the optional system property com.atomikos.icatch.file are applied
- any overrides set in a programmatic way are applied
- any overrides set a system properties are applied
- placeholder substitution is done for the resulting set of properties
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:
Configurationclass was moved to package
UserTransactionServiceno longer has the
init(TSInitInfo)method: initialisation now takes either no arguments, or a
Various details are explained below… Enjoy!http://www.hanselman.com/blog/OnTheNightmareThatIsJSONDatesPlusJSONNETAndASPNETWebAPI.aspx for some background information.
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.`
147436: Exceptions concerning log and/or configuration files should report the expected file location
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.
148495: Move methods from deprecated TransactionControl to CompositeTransaction and remove TransactionControl
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.
116801: Redesign recovery to avoid serialising participants so we keep memory usage low and minimize heuristic overhead
We now avoid serialisation with our brand-new recovery implementation.
135128: Separate OLTP logic from restart/recovery logic to simplify the transaction states and handlers
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.
148219: Dynamic XAResource registration: use hashCode rather than toString to generate a resource name
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.http://fogbugz.atomikos.com/default.asp?community.6.3133.0
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.