The Transaction mediator supports distributed transactions using the Java transaction API (JTA). When it comes to distributed transactions, it involves accessing and updating data on two or more networked computers, often using multiple databases. For example, two databases or a database and a message queue such as JMS. You can use the Synapse configuration language to define when to start, commit, or roll back the transaction. For example, you can mark the start of a transaction at the start of a database commit, mark the end of the transaction at the end of database commit and roll back the transaction if an error occurs.
Let's explore a basic transaction mediator scenario that demonstrates how the transaction mediator can be used to manage complex distributed transactions.
Transaction mediator scenario
You have a record in one database and you want to delete that record from the first database and add it to a second database. Assume that these two databases can either be run on the same server or can be in two remote servers. The database tables are defined in a way that the same entry cannot be added twice. Therefore, in the successful scenario, the record will be deleted from the first database and will be added to the second database. In the failure scenario, the record is already in the second database, hence the record will not be deleted from the first table nor will it be added into the second database.
- Windows, Linux or Solaris operating systems with WSO2 ESB installed.
- Apache Derby database server. If you do not have the Apache Derby database set up, download the Apache Derby distribution from http://db.apache.org.
Configuring the example scenario
Copy and paste the following configuration into
The sample configuration used here is similar to sample 361. Here via the In sequence a message is sent to the service, and via the Out sequence an entry from the first database is deleted and the second database is updated with that entry. If an entry that already exists is added once again to the second database, the entire transaction will roll back.
Setup two distributed Derby databases esbdb and esbdb1. For instructions on setting up the Derby databases, see Setting up the Derby database server.
Create a table in esbdb by executing the following statement.
Create a table in esbdb1 by executing the following statement.
Insert records into the two tables that you created by executing the following statements.
To insert records into the table in esbdb
To insert records into the table in esbdb1
When inserting records into the tables, the order of the record matters.
master-datasources.xmlfile located in the <
ESB_HOME>/repository/conf/datasourcesdirectory, create data source declarations for the distributed databases, ensuring that the datasource file names are
- Deploy the back-end service
SimpleStockQuoteService. For instructions on deploying sample back-end services, see Deploying sample back-end services.
Start the Axis2 server. For instructions on starting the Axis2 server, see Starting the Axis2 server.
Testing the example scenario
To test the successful scenario
Execute the following command from the
Executing this command removes the IBM record from the first database and adds it to the second database.
When you check both databases you will see that the IBM record is deleted from the first database and added to the second database.
To test the f ailure scenario
Execute the following command from the
Executing this command attempts to add an already existing record again to the second database, which results in the fault sequence being executed. You will see an exception raised for duplicate entries and the entire transaction will roll back.
When you check both databases you will see that a record is neither deleted from the first database nor added into the second database.