10.5. Deploy and Run the Transactional Route
Overview
After creating the Derby database instance, you are ready to deploy the OSGi bundles into the container and test the route, as described here.
Steps to deploy and run the transactional route
Perform the following steps to deploy and run the transactional route in the Red Hat JBoss Fuse OSGi container:
- Create the Derby database instance for the tutorial and create the
accounts
table, as follows:- Open a command prompt and change directory to the Derby system directory that you specified earlier (that is, the value of the
derby.system.home
system property). - Start the Derby database client utility,
ij
, by entering the following command:ij
NoteBy default,ij
takes the current working directory to be the Derby system directory. - Create the
txXaTutorial
database instance, by entering the followingij
command:ij> CONNECT 'jdbc:derby:txXaTutorial;create=true';
- Create the
accounts
table and create two sample row entries, by entering the following sequence ofij
commands:ij> CREATE TABLE accounts (name VARCHAR(50), amount INT); ij> INSERT INTO accounts (name,amount) VALUES ('Major Clanger',2000); ij> INSERT INTO accounts (name,amount) VALUES ('Tiny Clanger',100);
- Exit
ij
, by entering the following command (don't forget the semicolon):ij> EXIT;
- Open a new command prompt and start the JBoss Fuse OSGi container by entering the following command:
./fuse
- Install the
transaction
feature into the OSGi container. Enter the following console command:JBossFuse:karaf@root> features:install transaction
- Install the
spring-jdbc
feature into the OSGi container. Enter the following console command:JBossFuse:karaf@root> features:install spring-jdbc
- Install the
derby
bundle into the OSGi container. Enter the following console command, replacing the bundle version with whatever version of Derby you are using:JBossFuse:karaf@root> install mvn:org.apache.derby/derby/10.10.1.1
- Install and start the
derby-ds
bundle (assuming that you have already built the bundle, as described in Section 10.3, “Define a Derby Datasource”) by entering the following console command:JBossFuse:karaf@root> install -s mvn:org.fusesource.example/derby-ds/1.0-SNAPSHOT
- To check that the datasources have been successfully exported from the
derby-ds
bundle, list thederby-ds
services using theosgi:ls
command. For example, given that BundleID is the bundle ID for thederby-ds
bundle, you would enter the following console command:JBossFuse:karaf@root> osgi:ls BundleID
Amongst the exported services, you should see an entry like the following:---- aries.xa.aware = true aries.xa.name = derbyDS datasource.name = derbyXADB objectClass = javax.sql.DataSource osgi.service.blueprint.compname = derbyXADataSource service.id = 424 ----
This is the wrapped XA datasource (recognizable from thearies.xa.aware = true
setting), which is automatically created by the Aries wrapper feature (see Apache Aries Auto-Enlisting XA Wrapper). - Install and start the
tx-xa
bundle, by entering the following console command:JBossFuse:karaf@root> install -s mvn:org.fusesource.example/tx-xa
- Create a file called
giro1.xml
in any convenient directory and use a text editor to add the following message contents to it:<transaction> <transfer> <sender>Major Clanger</sender> <receiver>Tiny Clanger</receiver> <amount>90</amount> </transfer> </transaction>
Now copygiro1.xml
into the PathNameToMsgDir directory you created earlier (see Section 10.4, “Define a Transactional Route”). Thegiro1.xml
file should disappear immediately after it is copied, because the PathNameToMsgDir is being monitored by the feeder route. - Use the JMX console to see what has happened to the message in
giro1.xml
. Open a new command prompt and enter the following command (provided with the standard JDK):jconsole
In the JConsole: New Connection screen, select theorg.apache.karaf.main.Main
local process and click Connect. - Click on the MBean tab and use the tree in the left-hand column to navigate to org.apache.activemq | TxXaDemo | Queue | statusLog | Operations, as shown in the following screenshot.
Figure 10.1. JMX Operations Supported by the statusLog Queue
- Now in the right hand pane of the JConsole window, click
browse
(the version of the method that takes no arguments). The Operation return value dialog pops up as shown , which enables you to browse all of the messages currently pending in thestatusLog
queueue.Figure 10.2. JMX Browsing the statusLog Queue
In the example shown here, there is just one message in the queue. If you scroll down, you can see the Text field, which holds the body of the JMS message. The body contains the most recent result of calling theAccountService.dumpTable()
method (which is called in the last step of the transactional route). - You can also force a transaction rollback by sending a message that exceeds the
AccountService.debit()
limit (withdrawal limit) of 100. For example, create the filegiro2.xml
and add the following message contents to it:<transaction> <transfer> <sender>Major Clanger</sender> <receiver>Tiny Clanger</receiver> <amount>150</amount> </transfer> </transaction>
When you copy this file into the PathNameToMsgDir directory, the message never propagates through to thestatusLog
queue, because the transaction gets rolled back.