Why I hate the phrase “Long Running Transactions”…

I always talk about "Long Running Work" and steadfastly avoid "Long Running Transactions"...  My preference is to use the word "transaction" to mean an atomic operation that occurs at a single service within a second or so.  I mean the ACID (Atomic Consistent Isolated Durable) transactions that usually involve holding locks and that we transaction theorists love.

Whenever I hear about a "Long Running Transaction", I wonder about where it ends.  Let's consider the following example:
1) I decide to take a trip to Europe so I book some airline and hotel reservations.
2) The hotel in London hits a threshold of occupancy and decides to increase staffing and food for the restaurant.
3) The hotel orders more food from the Green Grocer.
4) The Green Grocer hits a threshold and orders another delivery from its shipper.
5) The shipping company hits a thresold and orders more diesel fuel for its trucks...
6) Two weeks later, I cancel my trip.

So, if I believe in long-running-transactions, the shipping company doesn't need any more diesel fuel!  I don't think so!

The long-running-transaction approach assumes that there is a cohesive set of work across loosely-coupled and independent systems that is atomic.  Notice it is not ACID in that Isolation is clearly different and Consistency is clearly different.  Hence, you would consider these "long-running-transactions" to exhibit Atomicity and Durability.  I am arguing that Atomicity is not a property that flows across multiple services as the semantics of interaction across these services is not tightly associated.

My preference is to talk about "long-running-work" across two services.  I can examine the semantic interaction of two services across a set of messages.  This leads to the notions of reliable messaging (and multi-message dialogs) which is one of my favorite topics and something I will be posting more work to my website (www.pathelland.com) soon.  It also leads to the notion of a contract across the messages that flow between two services.  I love these concepts. 

Another concept that I am strongly in favor of is the concept of a service being in the midst of multiple related dialogs.  My attempt to book travel arrangements puts me in multiple interactions with different airlines and hotels.  These interactions involve multiple messages and continue at least until the date of my travel (unless I cancel).  When my incoming reservation causes the hotel to increase its food requirements, the hotel will use business logic to control the relationship between my incoming messages and the restaurant related messages.  This allows it to consider the wisdom of canceling the food order when I cancel my reservation... very different than mindlessly assuming some coordinator associates these into a long-running-transaction.

Work flows across services and businesses in ways that do not magically "undo" even if you do master the use of compensations rather than the classic "undo" of replacing the before values.  The behavior of our interconnected systems is more an integration of lots of disparate work into summaries.  When I through a rock into the ocean by San Francisco, that can and does impact the waves that hit Tokyo but only in conjunction with countless other stimuli.

This is why I like to talk about long-running-work inside a single service or across exactly two services using a multi-message dialog.  The phrase long-running-transaction is a chimera and leads to a false hope of simplicity.  The reality is much richer and more complex.

Love, Pat

Comments (9)
  1. Thanks Pat, this needed to be said.

    I go even further, I will not talk about long running transactions when coordinating work between services (e.g. when I want to update the order in the sales system and the sales commision in my hown grown commision system). I’ll call that a short running process or an activity, because I don’t believe a should take long, nor do I believe, like you, that it is a transaction (in the ACID sense).

  2. Pat – how about reviving the retro name "saga"? This also has the connotation of a story, which has a defined beginning and end (even though of course the world in which the story is told does not).


  3. John Evdemon says:

    Are we talking about two entirely different types of transactions? A transaction in the ACID sense implies a sequence of exchanges and/or activities to be treated as a single unit of work. A "business" transaction may consists of many ACID and non-ACID activities (some of which may trigger an exception at the "business" transaction (parent) level while others may fail with minor impact). Business transactions can be modeled but are not easily reified into bits (not yet anyway…)

    Is a business transaction a business process or simply a component of a business process? Some standards organizations have identified six distinct Business Collaboration Patterns (Negotiation, Order Fulfillment, Long Term Contracts, Settlements, Escalating Commitments). Each of these Business Collaboration Patterns can be further broken down into six types of Business Transaction Patterns (Commercial Transaction, Request/Confirm, Query/Response, Request/Response, Notification and Information Distribution). A Business Process might contain many Business Collaboration Patterns, each of which could be broken down into a Business Transaction Pattern. A Business Transaction Pattern may contain several ACID-like transactions.

Comments are closed.

Skip to main content