1. Jan 1st, 2007

    2PC or not 2PC

    Dan Pritchett follows his first post with more thoughts about living in a world free from 2pc commit:

    • The only way out is through.
    • A call to order is in order.
    • It’s better to be an orphan than an empty nester.
    • Better late than never.
    • Idempotent operations are your friend.

    So 2PC or not 2PC?

    Dan lists the common techniques for building reliable and scalable applications. Depending on your application logic, you’re looking at order of operations, idempotence, asynchronous processing, compensation, etc.

    All these techniques work like the color palette of a painter. Which colors you pick, how you mix them together, where you draw them on the canvas depends on the image you’re painting.

    During the development process, you’re making these decisions as you’re building up the application.

    But during the initial design phase, such answers may easily fall on deaf ears. You’re thinking high-level without getting deep in the details of each functional unit. The sound of hammers is more pleasing.

    You say “we’re going to trust our skills and apply the right tool,” and someone else hears “we’re going to slip the schedule while we’re re-inventing the wheel”. When you’re looking for a definite answer, 2PC has more to offer.

    On paper.

    You still need to worry about order of operations to prevent deadlocks. You still have to deal with idempotency in user-facing interactions. You still need asynchronous processing for longer tasks. You still need to consider compensation. All too often, 2PC just buys you the illusion of simplicity.

    And it brings its own operational baggage. Dealing with deadlocks, hanging transactions and heuristic outcomes is notoriously hard.

    The majority of business transactions are performed with limited or no 2PC for a reason. And with the proliferation of services, we’re going to see that pattern amplified, as 2PC proves to be too fragile in practice.

    It was only a few years ago when I changed my mind about 2PC. Coming from the world of tightly integrated client-server, I thought of 2PC as an architectural choice, the natural basis for implementations. But in a world of distributed applications that need to collaborate with each, 2PC became a design choice, a trick you would pull out on rare occassions when no other solution will do.

    Where do you stand?

    Image by a little azorean.

    Printable PDF | Posted by Assaf Filed in general 5 Comments »

    1. Jan 2nd, 2007

      Sterling Camden

      2PC is one of those insurance policies that you pay for several times before you ever need it.

    2. Jan 2nd, 2007

      Assaf

      that’s a fair damage assement.

    3. Jan 5th, 2007

      Paul

      2PC is an API and thus to be used only within the bounds of a contiguous (i.e., single machine or small network) piece of software. On the plus side and as an API, 2PC gives you a way to package up something like a database or a message queue in a way that makes it straightforward for not-necessarily-as-clever folks to make productive use of it. If people are so inclined, they can still figure out what’s idempotent and who goes last, etc., but that isn’t a requirement.

    4. Jan 5th, 2007

      Assaf

      I’m fine with “let’s not think too much and just do the simplest thing that works” approach to 2PC. Unfortunately, the prevailing view of 2PC is the opposite of that.

    5. Mar 19th, 2007

      mult.ifario.us : Not Quite No Transactions

      [...] disentangle design choices from business constraints, and this is more or less the point that Assaf made in the original round of discussion about Dan Pritchett’s presentation. As Dare Obasanjo and [...]

    Your comment, here ⇓