147: Distributed Computing: Ready? Yes. Done.

Two-phase and three-phase commits will help you design solutions that need to work across multiple computers. Let’s say that you’re working on an event reservation application. You need to transfer some money to several vendors for a large event. Maybe one of the vendors is a food catering company and they’re waiting for the payment before they begin preparation. Another vendor is a local hotel that is waiting payment to reserve a meeting room. You send the food payment and it goes through. But the hotel refuses your payment because the room is now reserved for another customer. What do you do? Most likely, you now need to go back to the food vendor and try to cancel your order. If they refuse, then you’re in trouble. What if instead, there was a system in place that both the food vendor and the hotel agreed to work with that helped coordinate things like this. It’s actually good business for them both because they can advertise their relationship and highlight the benefits it gives to you. This new system lets you place the food order and the room reservation and get them both ready to go before you send the final instruction to proceed. Any problems will be discovered before you proceed with either vendor. This is called a two-phase commit. You send a message to each system asking if there are any problems and they all have to reply back to you before you then send another message to each one to proceed. We can turn this into a three-phase commit by first making sure everything is ready to proceed, then instead of committing right away, send a message to go ahead and actually do the work. But the important point is that when the work is being done, the final commitment is not given yet. We want to wait until as much work has been done as possible and only when each vendor has said everything is done and waiting for the final word, only then do we commit. Make sure to listen to the full episode for more information and advice. You can also read the full transcript below. Transcript Imagine you and a friend are talking and you both agree to do something together. You’ll complete half of the work and your friend will do the other half. You each go about your work and after a few days and a lot of hard work, you call your friend to ask when you can put everything together. This is when you find out that your friend ran into a problem and stopped working. All your work is ruined because there’s no way you can complete everything on your own. Computers face the same problems all the time. This episode will explain the problem in more detail and give you some advice for how to handle multiple computers that need to coordinate activities. The problem doesn’t even really need multiple computers. Multiple separate transactions are enough as long as they all need to be treated as one overall transaction. Let’s say that you’re working on an event reservation application. You need to transfer some money to several vendors for a large event. Maybe one of the vendors is a food catering company and they’re waiting for the payment before they begin preparation. Another vendor is a local hotel that is waiting payment to reserve a meeting room. You send the food payment and it goes through. But the hotel refuses your payment because the room is now reserved for another customer. What do you do? Most likely, you now need to go back to the food vendor and try to cancel your order. If they refuse, then you’re in trouble. What if instead, there was a system in place that both the food vendor and the hotel agreed to work with that helped coordinate things like this. It’s actually good business for them both because they can advertise their relationship and highlight the benefits it gives to you. This new system lets you place the food order and the room reservation and get them both ready to go before you send the final instruction to proceed. Any problems will be discov