Tony Bain

Building products & teams that leverage data, analytics, AI & automation to do amazing things

The Transactional Dilemma of Seat 25D

August 19, 2008 | Tony Bain

I was on major domestic airline last night, flying from Melbourne to Sydney (a pretty standard flight for me). Notice in front of me a couple taking their seats. Then a man got walked down the isle, looked at his ticket and questioned the couple as if they were in the wrong seat. No they weren’t it appeared the two people had been allocated the same seat. Moments later another gentleman walked down the isle ticket in hand, and again questioned the couple as to if they were in the wrong seat. Again no, so now three people had been allocated the same seat. A few minutes passed as a slightly stressed flight attendant tried to work out how to fix this when a woman who was running late hurried down the isle, politely excused herself around the queue of people standing there, looked at her ticket and questioned the couple if they were sitting in the wrong seat. 4 people had all been allocated a single seat which of course was a major issue on a full flight.

Now the interesting thing is why this happened. You may put this down to software glitch, but it is more than that. Without doubt all of the check-in information is sitting on-top of a relational database platform. Now the crux of the matter is, if the application developer of the check in system was using the most appropriate isolation level and undertaking proper transaction control, this could not have happened. It would have been possible for 2 people to end up with the same seat, let alone 4 people.

But it did happen. And why is that. Well firstly, it could be just a stuff up of the application vendor, however double ups happen all the time so if this was the case then likely this particular issue would have been fixed long ago. Instead, a much more likely cause is that the application vendor and/or customer has made the decision to forgo strict transaction control for better concurrency, that is better performance during peak times. Strict transaction control results in reduced concurrency as one transaction often has to wait for another transaction to complete processing before it can in turn complete processing. So when you are checking in loads of people on loads of airplanes, all within a short period of time your primary concern is ensuring you do this as quickly as possible. Obviously the decision has been made somewhere that doing so quickly is more important than the occasional double allocation of a seat which the flight attendants can usually fix up without too much issue.

Why I am bringing this up, is that this is the model that is currently in favor and more and more systems used on scale are moving towards. In my “Performance Trumps Everything” article I spoke of how the desire for mass scalability and performance is causing the deprecation of age old features such as strict transaction control. While this model does present benefits for many scenarios in the data tier, this is a clear real world example that if you go down this route you have to take on extra responsibility in the application tiers for ensuring data integrity is maintained.