Transactions through the Ages

I commented briefly yesterday about how the same things come up time after time with different names. One of the best examples of this is Transactions; that is distributed 2 phase commit type transactions. I was first told about transactions in 1972 sitting in front of a mainframe IBM 360 model 40 on night shift by a programmer who was teaching me PL/1. He explained how 2 phase commit (2PC) worked and told me the oldest example of a 2 phase commit was the wedding ceremony.


In the ceremony the man agrees to marry and then the woman agrees to marry but until the minister says they are married they are not married. Prior to that point either party can back out, after that point the two people are married; this is the commit point of the service or the 2 phase commit.

Back in those days this was an interesting and fun (!) story and piece of technology but it has begun to pall a bit over the years as each generation of new computing users discover it.


After I used it in those very early days a few years later I started working on CICS systems and had it explained to me again. Then moving onto UNIX systems I went to a talk about these new relational databases from Oracle and had it explained again. Next was Tuxedo, still on UNIX, and XA compliance. I then did a Phd thesis on Transactional Microkernels which covered integrating Transactions into the OS kernel as first class citizens alongside processes. Surely I wouldn’t ever have to have transactions explained to me again; then I joined Microsoft in 1994.


Back in those days MS had only just got into real OS’es with NT 3.1 and so when I turned up and said that my technical specialisation was transaction systems I got put in charge of NT and SQL Server. I remember my boss at the time looking blank when I said I really understood high throughput transactional systems and telling me “You had better look after SQL Server then”. This was 4.21a, hardly a high performance transaction system!


Then I went to a conference at Microsoft Corp headquarters and surprise surprise, Pat Helland stood up and told us about Transactions again, including the wedding story, before going on to talk about Microsoft Transaction Server. Whilst new for most people it was really getting old for me.


Anyway last week I was again at a conference and the talk once again turned to transactions, this time in regard to WS-Trans. The various parts of WS-Trans were explained but thankfully no one covered what 2PC was and so I was spared the wedding story.

Of course there is a fundamental disconnect between the 2PC closely coupled aspect of the first part of WS-Trans and the concept of business level functionality and loose coupling espoused by SOA that I talked about yesterday. This has been clear for a while so I was delighted when someone bought it up in a question and even better, most people in the room (including the presenters) understood the issue. At last we seem to have moved on from the basics to more interesting levels of discussions around transactions; it’s only taken 32 years and 6 generations (2x on mainframes, 2x on Unix and 2x on Windows). I will talk about the WS-Trans issue in more detail in a future blog.


One of my interview questions is how many times have you had the same technical concepts explained to you in terms of a new technology; its surprising how many of the “brand new” latest technologies have been around many many times before. From this interview question you can categorise yourself into a 1st, 2nd, 3rd and so on generation computing person. What generation computing person are you and can anyone beat a 6?

Comments (8)

  1. Tim Sneath says:

    1972? Some typo surely? I wasn’t even _born_ then… 🙂

  2. Michael Platt says:

    Alas no, that when I got my first job in computing working for IBM.

    Any you thought I was in my 20’s!!

  3. Ian Griffiths says:

    So you can back out after saying "I do" can you?

    I’ve only had that story explained to me a couple of times, but I’ve always heard it said that once you’ve gone past the "I do" phase, although you’re not married until the TX commits, it’s too late for you to elect to abort. (It’s still possible for an abort to occur after this point, it’s just that you don’t get to be the cause of the abort if you’ve already said "I do".) So did you really mean to say that either part can back out at any point prior to the minister saying they are married (i.e. even after they’ve said "I do")?

    Or do I need to hear this story another 4 times before I’ll understand it?

  4. RichB says:

    I first heard the Wedding story in "Principles of Transaction Processing" by Bernstein & Newcomer – a great book.

    Several of the GoF design patterns are not specific to OOP and have been around for decades. My favourite is "Chain of Responsibility", which people have been using since assembler was the primary computer language.

  5. Michael Platt says:

    Yes, thats true. Both in the wedding service and in 2PC once you have commited (a 1PC) then you cannot back out. I meant from a global rather than individual perspective either party can back out, eg you can say I do and the other party say they dont.

    As you say both parties can commit and the marrige still fail if there is some outside effect, eg the vicar is taken ill (not all that strange, I have seen it happen!).

    Of course the interesting thing both in computing and in marrige is the failing case. Things get much more complex then!

  6. Michael Platt says:

    Yes, the Bernstein book is good but I prefer Grey and Reuter Concepts and Techniques:*

    The original TP bible and my handbook for many years

  7. Ramkumar Kothandaraman says:

    Mike – I am not sure if your ‘method’ of determining generations is robust. Consider this example: In the past 5 years, the concept of pipelines have been rehased and rechristened several times – Initially it was simply pipeline and pipeline components, then Pipes and Filters pattern and now AOP (aspect oriented programming).

  8. Michael Platt says:

    Ram. Yes you are quite right, it is an interview question so wide open and not in the slightest bit robust. The answers people give are always illuminating though.

    Data access has a similar problem as pipelines.

Skip to main content