Cloud Foundry: Design and Architecture
Derek Collison discusses the goals, the design premises and patterns employed in creating the architecture of Cloud Foundry, VMware’s open source PaaS, unveiling internal architectural details.
Presentation
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Recorded at:
Transactions without Transactions
How would you like to view the presentation?
In case you are having issues watching this video, please follow these simple steps to help us investigate the issue:
1. Right click on the video player and select Copy log
2. Paste the copied information in an email to video-issue@infoq.com (clicking this link will fill in the default details in most email clients).
Note: in case your email client hasn't automatically picked up the email subject, please include in your email the URL of the video too.
3. Done.
We will investigate the issue and get back to you as soon as possible. Thanks for helping us improve our site!
1. Right click on the video player and select Copy log
2. Paste the copied information in an email to video-issue@infoq.com (clicking this link will fill in the default details in most email clients).
Note: in case your email client hasn't automatically picked up the email subject, please include in your email the URL of the video too.
3. Done.
We will investigate the issue and get back to you as soon as possible. Thanks for helping us improve our site!
Summary
Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.
Bio
Richard Kreuter and Kyle Banker work as software engineers for 10gen, the company behind MongoDB.
About the conference
Strange Loop is a multi-disciplinary conference that aims to bring together the developers and thinkers building tomorrow's technology in fields such as emerging languages, alternative databases, concurrency, distributed systems, mobile development, and the web.
Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.
Bio
Richard Kreuter and Kyle Banker work as software engineers for 10gen, the company behind MongoDB.
About the conference
Strange Loop is a multi-disciplinary conference that aims to bring together the developers and thinkers building tomorrow's technology in fields such as emerging languages, alternative databases, concurrency, distributed systems, mobile development, and the web.
RelatedVendorContent
Introducing SQLFire: a memory-optimized, high performance SQL database
RDBMS to NoSQL: Managing the Transition
Banking Case Study: Scaling with Low Latency using NewSQL
Related Sponsor
Neo4j is a robust, high-performance, scalable graph database. It is the only NOSQL database that solves the complex, connected data challenges that enterprises face today.
- This article is part of a featured topic series on NoSQL
- See more NoSQL content at: http://www.infoq.com/NoSQL
- Other recent content items in this topic
Strange Loop
by
Alex Miller
Posted
Ticket Sales Atomicity
by
Dave Sturgeon
Posted
Interesting
by
Duraid Duraid
Posted
More effort and complexity
by
Roger Fischer
Posted
so, er, distributed TP monitors. I must be getting old.
by
Scott Finnie
Posted
Transactions without Transactions
by
JOel MAmedov
Posted
Re: Transactions without Transactions
by
Dan Liang
Posted
Transactional Messaging
by
Siva Kumar
Posted
-
If you're interested in other upcoming videos from Strange Loop, the full release schedule is here and all slides are here. If you want to be notified about Strange Loop announcements in the future, sign up for the mailing list.
-
wrt the Ticket Sales example.. If there are only 2 seats left and 2 separate processes try and reserve both at the same time, then you may have a situation where by each process is only able to move one of the tickets into the IN_CART status. Both processes effectively initiate a compensatory action which moves both tickets back to an AVAILABLE status.. You end up missing out on selling tickets for which you had 2 buyers for.. did I miss something ?
-
I totaly agree with the concept of using RDBMS transactions with caution and avoid using them to model business transactions to avoid coupling as was mentioned in the presentation.
However, I'm still not convinced that you need to model all the transactions at the application. In my view, I think you still need atomicity at the scope of an operation on single database. For example if you have 2 entities a parent and a child and you want the child to be deleted if the parent is deleted then you need transactions to do that otherwise if you model it in the application then you will increase the complexity of the application tremendously.
If software managed transactions are being introduced to in languages (like clojure) and frameworks to ease the development of concurrent operation then for sure transactions have their use in persistent data stores which are concurrent by nature. -
The problem is that one has to implement all the detection and compensation code. That is not simple.
The ticket sales example isn't any more realistic than the bank transfer. Nobody would implement the whole sale in a single transaction.
The realistic parts are where multiple tickets need to transit state in unison. That is trivial with transactions (and very short lived), but quite a bit of code without transactions.
Also in the ticket example the target object (ticket) is essentially locked for an extended period. What if the target object needs to be updated by other transactions?
What if a part of the transaction is an increment (or similar)? On a failure how do you know if the increment was applied or not? -
So summarising the slides:
- in distributed systems you can't rely on the transaction capabilities of a single database.
- but the real world problem you're dealing with still needs transactional semantics (e.g. conservation of money)
- so build the logic of a distributed transaction manager in your application code base.
- Use transactional asynchronous messaging to communicate among the nodes in your network.
- manage the transaction as a multi-step state machine, with identified compensatory actions should any transition in the state machine fail.
Sounds a lot like the problem that spawned distributed transaction monitors 20 years ago. The tech world really does go round in circles sometimes. Wonder if Tuxedo, Top End and their ilk will rise phoenix-like? -
I did not have patience to seat through entire presentation. Because of simplistic view and examples provided.
Well, what happens if compensating transaction fails? What happens in highly concurrent environment? -
Is Transactional Messaging currently supported by MongoDB?
-
The idea is the leasing - you put a transient lock to the data while you are working on it. In normal case you would move the data out of the transient state and into a stable state when you are done. Worst comes worst the data store will do the clean up of that piece of data when the lease expires.
8 comments
Watch Thread Reply