Skip to content


Subversion checkout URL

You can clone with
Download ZIP
Fetching latest commit...
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.


This example shows how you can make your web services transactional. [It uses Jersey and Grizzly
for deploying the participant web services, but any conforming web container will do].

Deploy the rest-tx war (rest-tx-web-5.0.0.M2-SNAPSHOT.war) into a running AS7 (or AS6) application server
that is listening for http requests on localhost (if you use a different host/port change the url in

mvn clean compile exec:exec

or use the or run.bat script.


[The examples run under the control of maven so you will need to filter maven output from example output.]

1. You will see 2 lines of output showing the service enlisting into the transaction:
	Service: Enlisting <http://localhost:58082/service/1/participant>; rel="participant",<http://localhost:58082/service/1/terminator>; rel="terminator"
	Service: Enlisting <http://localhost:58082/service/2/participant>; rel="participant",<http://localhost:58082/service/2/terminator>; rel="terminator"

2. A message showing the client committing transaction:

	Client: Committing transaction

3. A prepare and commit message is generated by each service work unit. This is repeated for both
work units:

	Service: PUT request to terminate url: wId=2, status:=txStatus=TransactionPrepared
	Service: PUT request to terminate url: wId=1, status:=txStatus=TransactionPrepared
	Service: PUT request to terminate url: wId=1, status:=txStatus=TransactionCommitted
	Service: PUT request to terminate url: wId=2, status:=txStatus=TransactionCommitted

4. The client checks that the service got both commit requests:

	SUCCESS: Both service work loads received commit requests

1. We deployed a JAX-RS servlet that implements a RESTful interface to the Narayana transaction manager (TM)
(running in an AS7 or AS6 container).

2. The client ( started an embedded web server ( for hosting web services.

3 The client then started a REST Atomic Transaction and got back two urls: one for completing the transaction
and one for use with enlisting durable participants (implemented by the class
into the transaction.

4. The client then made two HTTP requests to a web service and passed the participant enlistment url as part
of the context of the request (using a query parameter).

5. The participants used the enlistment url to join the transaction. In this naive example we assumes that
each request is for a separate unit of transactional work and in this way we end up with multiple participants
being involved in the transaction. Having more than one participant means we can demonstrate that either all
participants will commit or none them will.

6. The client commits the transaction using the resource url it got back when it created the transaction.

7. The transaction manager implementation knows that there are two resources involved and asks them both to
prepare their work (using the resource urls it got from the participants when they enlisted into the transaction).
If the participant resources respond with the correct HTTP status code and body then the transaction manager
proceeds to request commitment. Refer to the REST Atomic Transactions spec for full details.

8. The client sends a request to the service asking how many times it was asked to commit work units.
If it was twice then SUCCESS is printed otherwise FAILURE is printed.
Something went wrong with that request. Please try again.