Transaction Tribulation

Transactions allow us to treat a composite action as an atomic one. A benefit of transactions is that they compose safely, without risk of deadlock. Unfortunately, transactions are a mediocre basis for concurrency control at both large and small scales. Some points:

  1. Large transactions have high risk of disruption and rework. By nature, transactions must be limited to small-scale tasks.
  2. Transactions aid us by increasing the granularity of our commands. If we keep them small, we still face all the same concurrency issues once our commands cross multiple transactions.
  3. A compositional system requires distributed transactions, i.e. such that a client can invoke two services in a single transaction. Without this, we’re forced to provide a monolithic service and database to serve all client requirements.
  4. If we use distributed transactions, it becomes difficult to control their scope. We can introduce transaction barriers (i.e. that delay messages until commit) but we can only control those in a small subset of the application.
  5. Transactions are not very robust in a security sense. I.e. they are very vulnerable to denial of service attacks. We can mitigate this with priority, but administrators for different services in a system are unlikely to agree with your priority requests.
  6. Transactions don’t integrate well at the edges – sensors, actuators. Sensors often provide continuous data streams, and are subject to data fusion, so no clear transactional boundaries exist. Actuators cannot generally ‘undo’.
  7. The need to redo work makes the transactional model invalid for hard real-time systems.

I pursued transactions as a basis for concurrency control for a couple years before developing RDP. One example of my efforts is transactional actors model. But I became disillusioned and embittered with transactions as they caused headaches for scalable semantics and implementation, proved infeasible for embedded real-time control systems, and failed one pseudocode test after another. I believe I’ve offered transactions a fair trial.

Transactions are not terrible. I would never have pursued them if they were entirely ineffective. In terms of scalability and security and composition, transactions are certainly superior to mutexes, and compare well to promise pipelining models.

But transactions are not sufficient for my vision.

I have since returned to temporal models, where time is modeled explicitly. I initially disregarded temporal models due to perceived difficulty with clock drift, performance, and consistency at scale. However, I’ve since found that explicitly modeling delay can both allow drift for performance and mask drift for consistency.

This entry was posted in Concurrency, Language Design, Open Systems Programming, State. Bookmark the permalink.

4 Responses to Transaction Tribulation

  1. Some people are pursuing transactions for embedded systems. Thomas Fuhrmann’s DecentVM supports software transactional memory and lock-based consistency via monitors. See his VMIL 2010 workshop paper. Rather than say it caused you headaches, see what others have done! I always wanted to pay closer attention to DecentVM myself.

    • dmbarbour says:

      I do not believe that ‘transactions for embedded systems’ solve even one of the above seven issues.

      [edit]: Embedded or hardware transactions might be useful machine primitives to safely implement a higher-level concurrency model (i.e. an alternative to CAS or LL/SC). This article is about using transactions when interacting with higher level abstractions.

      • My comments were responding to:

        proved infeasible for embedded real-time control systems

        As a side note, when I think of Transaction Actors, I think of guardians in distributed systems, a’la Hewitt and Lieberman’s AI Memo 505, which I have mentioned many times as a very good paper. Hewitt’s create_transaction_manager actor and also Hewitt’s banker and customer actors address your concerns about distinguishing between a message send and a message reply to you noted on the c2 wiki.

      • dmbarbour says:

        Small memory does not mean small abstractions. And ‘real-time control systems’ will involve continuous sensors and actuators with predicative delay.

        Thank you for the reference to Memo 505.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s