When ACID is too much... try magic mushrooms! ;) (only joking)
Sent from my HTC
----- Reply message -----
From: "LJC - London Java Community" <[address removed]>
Date: Thu, Aug 29,[masked]:56
Subject: You're invited to JBUG EVENT: Compensating Transactions: When ACID is too much
To: <[address removed]>
JBUG EVENT: Compensating Transactions: When ACID is too muchhttp://www.meetup.com/__ms12776247/Londonjavacommunity/events/137336992/t/ea1_grp/?rv=ea1&_af_eid=137336992&_af=event&expires=1377968174393&sig=b25121cdb8fd21fdad91dfa9dfa98428f00d7c2e
LJC - London Java Community
Added by Barry Cranford
Wednesday, September 25, 2013
The Skills Matter eXchange
[masked] Goswell Road
Will you attend?
2 Java Developers attending, including:
I founded the LJC as a group for Java developers to come together and meet each other...
I work for C2B2 Ltd- middleware consultancy company.
I'm also a London JBoss User Group Organiser.
PLEASE NOTE THIS IS A JBUG EVENT NOT AN LJC EVENT. WE ARE USING THE LJC TO GENERATE PUBLICITY OF THE EVENT. TO GUARANTEE A PLACE YOU MUST REGISTER YOUR DETAILS HERE: http://www.c2b2.co.uk/london_jbug_september_2013
JBUG EVENT: Compensating Transactions: When ACID is too much
ACID transactions are a useful tool for application developers and can provide very strong guarantees, even in the presence of failures. However, ACID transactions are not always appropriate for every situation.
ACID transactions are achieved by holding locks on resources and require the ability to rollback changes. In some situations, the blocking nature of the protocol can be too limiting to performance, especially if the transaction is distributed. Also, some actions can’t simply be rolled back; for example, sending an email.
A common strategy for applications that can’t use ACID, is to throw out transactions altogether. However, with this approach you are missing out on many of the benefits that transactions can provide. There are alternative transaction models that relax some of the ACID properties, while still retaining many of the strong guarantees essential for building robust enterprise applications. These should be considered before deciding not to use transactions at all.
In this talk, I’ll present one such alternative to ACID transactions: compensation-based transactions. I’ll provide an overview of ACID and it’s limitations and describe some use-cases where ACID is not appropriate. I’ll then present our new API for compensation-based transactions and demonstrate how it can be used to address these problems. Finally, I’ll present our future plans to improve and expand our support for compensation-based transactions.
To read the 'Compensating Transactions: When ACID is too much' blog series please visit http://bit.ly/142keMN
Dr Paul Robinson is a Senior Software Engineer at JBoss by Red Hat where he currently leads the Web Service Transactions project.
Paul has worked in the field of transactions and Java middleware for over 10 years. His experience began at Hewlett Packard where he was a member of the Transactions Team. Here he contributed to the first Web service transactions implem