Using a Spring configured full-blown transaction manager across modules in Z2

As does Sample-jta-plain, so does this sample demonstrate how to use Z2 with the Atomikos transaction manager. In this case however, we choose to use the Spring framework to configure the transaction manager and enable re-use using Z2's support for modular Spring applications (see also How to Spring).

The Wiki page How_to_TransactionManager explains the general principles behind transaction handling in Z2.

This sample is stored in z2-samples.jta-spring. It implements exactly the same scenario as Sample-spring-hibernate with the exception of not using the built-in JTA implementation.


Z2 has the following Java Version requirements

Z2 Version Min. Java version required Max Java version supported
2.1 - 2.3.1 Java 6 Java 7
2.4 - master Java 8 Java 8

Note: Most samples suggest to use the master branch. You may choose another version branch (please check the respective repository).
Make sure you have a corresponding Java Development Kit (JDK) or Java Runtime Environment (JRE) installed. If in doubt, go to Download Java SE.

Note: Running v2.1-v2.3.1 on Java 8 is supported by specifying

(or 6, if that is your desired compilation language level) in <home>/run/bin/ By this the Java compiler version detection does not fall back to a lower level.

You need to run Java DB as network server on localhost. This is explained next.

The application will create a database "z2-samples"

Running a Java DB Network Server

In samples we use the Java DB, i.e. the SQL database implementation that comes with the Java SE Development Kit (JDK) by Oracle (except for Mac OS in which case you have to use Apache Derby). Java DB is the same as the Apache Derby DB - see also the installation how-to.

The instructions below apply to both, there is only a difference in the installation path.

For general information on Java DB go to

To run the Java DB in server mode, which is what we want to do, run

mkdir derby
cd derby
java -jar $JAVA_HOME/db/lib/derbyrun.jar server start

assuming you want to run it in the folder derby. At a second time you can omit the "mkdir" command of course. The environment variable JAVA_HOME is expected to point to your JDK installation folder. When you installed Apache Derby and followed the instructions mentioned above, you have to replace $JAVA_HOME by $DERBY_HOME.

On Windows run

mkdir derby
cd derby
java -jar "%JAVA_HOME%\db\lib\derbyrun.jar" server start

In order to interactively query Java DB, we recommend to use the Data Source Explorer view in Eclipse. But any SQL client that can make use of JDBC drivers should be fine. The driver for Java DB can be found (at the time of this writing) in $JAVA_HOME/db/lib/derbyclient.jar (and similarly on Windows).

Note: If you have problems running Derby due to Security Exceptions, it may be necessary to update your security profile as described in (and please make sure you have a good JAVA_HOME and PATH setting).

Alternative: Using the DB-Worker Node Add-on (no separate RDBMS installation required)

you can also use the DB Worker Node Add-on which runs Apache Derby RDBM as a regular z2 worker process, so you don't need to install any extra database software.

How to augment the samples to use the DB Worker node?

You have to add the DB Worker Node Add-on to your samples environment and tell the server to start the DB worker node beside the web worker.
For this you can use the two files attached to this page:

  • - points to the z2 component repository containing the DB Worker Node Add-on
  • - a slightly changed home layout that launches the DB worker in addition to the web worker

Just download these two files and put them under .../install/z2-samples.XYZ/environment/ - where z2.samples.XYZ must be replaced by the concrete sample name like z2-samples.spring-hibernate

Running the sample

This sample is run as explained in How to run a sample. The 5 minutes version:

mkdir install
cd install 
git clone -b master
git clone -b master

# on Linux / Mac OS:
cd z2-base.core/run/bin

# on Windows:
cd z2-base.core\run\bin


When everything is up, go to http://localhost:8080/jta-spring. You see something like this:

And indeed, it's the same database we use elsewhere.

Now to the point...

This sample illustrates how to use a third-party transaction manager, the Atomikos implementation in this case, in a modular application as indicated in How_to_TransactionManager. This in conjunction with Spring resulting in a full-blown, highly adaptable and completely modular environment, scalable in deployment and development.

Unlike Sample-jta-plain, Atomikos configuration and set up of transaction manager and user transaction is done by Spring. This may be perceived a more consistent approach by Spring users.

Instead of invoking the JTA Transaction Manager interface directly, transaction demarcation is done using Spring's \@Transactional annotation (in the Controller). Note that Spring transaction de-marcation cannot be used with direct transaction manager usage at the same time (as Spring keeps additional context).

jta-spring-thingies.png (31 KB) Henning Blohm, 27.09.2012 22:42