![]() ![]() These state changes can either be rolled back or committed later once the outcome of the transaction has been determinned. In the first phase, each individual participant, of an ACID transaction, will make durable any state changes that were made during the scope of the transaction. This is the case for both ACID transactions and our compensation-based transactions model. Transaction systems typically use a two-phase protocol to acheive atomicity between participants. What is a ‘Compensation-based transaction’? In this series of blog posts I'll be focusing on the compensation-based approach. In the Narayana project, we have support for three Extended Transaction models "Nested Top Level Transactions", "Nested Transactions" and a compensation-based model based on "Sagas". These models are often referred to as "Extended Transaction models" and should be considered before deciding not to use transactions at all. There are many alternative transaction models that relax some of the ACID properties, while still retaining many of the strong guarantees essential for building robust enterprise applications. However, with this approach you are missing out on many of the benefits that transactions can provide. Also, some actions cannot simply be rolled back such as, the sending of an email or the invocation of some third-party service.Ī common strategy for applications that cannot use ACID, is to throw out transactions altogether. This can frequently be the case for transactions involving slow participants (humans, for example) or those distributed over high latency networks (such as the Internet). ![]() Both approaches can impose negative impacts on certain classes of applications, if the duration of the transaction exceeds a few seconds. The isolation property of an ACID transaction is typically achieved through optimistic or pessimistic concurrency control. I'll present several such scenarios and show how an alternative non-ACID transaction model can be used. However, ACID transactions are not always appropriate for every situation. Part 1: IntroductionĪCID transactions are a useful tool for application developers and can provide very strong guarantees, even in the presence of failures. Maybe I'll have a part 5, that covers this.Ĭompensating Transactions: When ACID is too much. I'll also be adding sections at the end of the talk, to explain what we have implemented so far and our future roadmap I'm not sure how much of this I will cover in the blog posts. The code examples will demonstrate the current design of the compensations API. The plan is to base my JUDCon:Boston talk roughly on this series of blog posts. I'm using this article as a place for the community to review a series of blog posts I'm preparing. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |