Month: October 2012

Play 2.0 framework and XA transactions

XA transactions are useful and out of the box, Play 2.0 today does not have support for them.  Here I show how to add that support: First off, some examples when XA is useful: - JPA uses two physical connections if you use entities from two different persistence.xml - those two connections might need to be committed in one transaction, so XA is your only option - Committing a change in a database and at the same time committing a message to JMS.  E.g. you want to guarantee that an email is sent after you successfully commit an order to the database, asynchronously.  There are other ways, but JMS provides a transactional way to do this with little overhead in having to think about failure. - Writing to a physically different database because of any of several political reasons (legacy system, different department responsible for different database server / different budgets). - See http://docs.codehaus.org/display/BTM/FAQ#FAQ-WhywouldIneedatransactionmanager So the way I see it, XA is something Play needs to "support". Adding support is very easy.  I have created a play plugin which is based on Bitronix.  Resources are configured in the Bitronix JNDI tree (why on earth does Play use a config file rather than JNDI?! anyway...)  You start the transaction like this, "withXaTransaction":     def someControllerMethod = Action {                     withXaTransaction { ctx =>                         TicketRepository. addValidation(user.get, bookingRef, ctx)                         ValidationRepository.addValidation(bookingRef, user.get, ctx)                     }    …

Read more