Some people will claim that REST does not need BPM because it provides all the semantics you need.

However, if you look beneath the hood then it turns out that this is not exactly true: in particular, if multiple (independent) REST services need to come to the same outcome then you want something more…

Wondering what that is? Good! It's all explained in one of our latest publications - to learn the details: just fill out this form.

Enjoy!

So you're into REST and you are wondering how to define some kind of transaction guarantee with it…

Look no further, because we have exactly what you need:

• A design pattern
• A simple, vendor-independent REST API
• Backed by a reusable coordinator service if you need one (that is up to you, really)

FREE download: "TCC for REST API" (API specification)

PS: the technology described in this specification is available and can be downloaded as part of TransactionsEssentials

126795: NullPointerException during borrowConnection in JMS with concurrent close of existing session

Fixed a NPE condition where concurrent borrow requests and close operations on existing sessions would interfere.

This post was based on old content and is no longer relevant.

Visit our Distributed Transactions Tutorial for equivalent content.

We found this nice tutorial by Gonçalo Marques covering basic two-phase commit with Spring, Tomcat and Atomikos.

Enjoy!

PS with our latest Tomcat integration - available to commercial subscribers - things are even easier