Share via

What is the Lighweight Transaction Manager and why do you need to know about it

  • Article

A "hidden" feature available in System.Transactions is the Lightweight Transaction Manager (LTM). It provides support for light weight transactions that live in the current appdomain. The LTM acts as a façade layer for all the transactions started in System.Transactions and based on a set of rules, it will "fallback" to an MSDTC distributed transaction when it is necessary. I call it "fallback" because there is some performance penalty that you need to pay when this happens: the transaction will span beyond the appdomain and there will be cross-process messages that will be sent, since MSDTC resides in a different process. (Note that from the TM functionality point of view, you can also call this a "promotion", since the MSDTC is a more general purpose and more complete TM). The fallback/promotion happens behind the scenes without any action required from the application developer.

As long as the LTM deals with volatile resources (that enlist using Transaction.EnlistVolatile) and with at most one durable resource that supports single phase notifications (this resource enlists with Transaction.EnlistDurable and implements ISinglePhaseNotification) then the transaction remains in the ownership of LTM. The LTM restricts itself only to those resources that live in the same appdomain and for which "logging" (writing the transaction outcome to the disk) is not required.

The fallback will take place and the LTM will transfer the ownership of the transaction to MSDTC if any of the following is true:
- at least one durable resource that doesn't support single phase notifications is enlisted in the transaction
- at least two durable resources that support single phase notifications are enlisted in the transaction
- a request to "marshal" the transaction to a different appdomain or different process is done.

In between the LTM transaction and MSDTC transaction there is one intermediary type of transaction that we sometimes call it "database transaction" that is made available through the Promotable Single Phase Enlistment. PSPE is another important mechanism in System.Transactions for performance optimization. It allows a remote durable resource, located in a different appdomain/process/machine, to participate in the LTM transaction without causing it to "fallback" to an MSDTC transaction.

Since the LTM is a "hidden" feature, the only reason for which you need to know about its existence is when you care a lot about performance. You will want to delay or avoid the fallback to MSDTC as much as possible to gain performance and for that you need to know how and when the fallback is triggered.

Comments

  • Anonymous
    May 15, 2005
    Would you explain the single phase/ Multi phase Transaction plz?

  • Anonymous
    May 16, 2005
    RePost:
    http://www.yeyan.cn/Database/TransactionManagerLighweight.aspx

  • Anonymous
    May 16, 2005
    As I understand it,
    LTM == Single Phase Transaction and
    DTC == Multi Phase Transaction..
    Is this right?

  • Anonymous
    May 17, 2005
    To: arnold

    In general, transactions are done in 2 Phase Commit or 2PC. In phase 1, the transaction manager sends "prepare" messages to the resource managers participating in transaction. Once the TM receives the answers from all the RMs, it will start phase 2. In phase 2, if all the RM answers were positive in phase 1, then a "commit" message is broadcasted, otherwise, the TM will "abort" the transaction.

    In some cases, the TM can optimize the 2-PC to a single phase commit, and instead of sending a "prepare" followed by "commit"/"abort", it will only send a SinglePhaseCommit. This optimization happens when only one durable resource manager is involved in the transaction.

  • Anonymous
    May 18, 2005
    Thanks a lot. It was very helpful.

  • Anonymous
    July 03, 2005
    Hi Florin
    I'm back again :)

    From what I understood, a connection to a SQLSvr2005 DB is considered as a durable RM which supports single phase notifications. Consequently, a tx which deals with one such cnx and several RM volatiles is managed by the LTM.

    On the other side, a connection to any other RDBMS than SqlSvr2005 (say SQLSvr2000) is considered as a durable RM which doesn't support single phase notifications. Consequently, LTM can't work with any SQLSvr2000 cnx. As soon as a SQLSvr2000 cnx is being enrolled in a tx, the DTC comes in the ring. This particular behavior is less efficient than using SQLSvr2000 with ADO.NET 1.

    Am I right?

    Cheers,
    Patrick

  • Anonymous
    August 08, 2005
    To: Patrick
    In your second scenario "SQLSvr2000 with ADO.NET 1" do you involve any transaction (like a transaction started by a ServicedComponent)? If you don't, then yes, you will get a small payload when you add transactions. But this payload may payback in the future, if you expect to add another database connection to your app. Or maybe SQL Server 2000 will support PSPE in the future.

  • Anonymous
    August 12, 2005
    The comment has been removed

  • Anonymous
    August 28, 2005
    To: kmv

    This is an optimization that System.Data should investigate if it is possible, but from what I remember they don't support sharing a transaction across multiple connections. From System.Transactions point of you, when you open the second connection, there is second call from System.Data to EnlistPromotableSinglePhase, to which we need to return false, because only one PSPE enlistment should be allowed per transaction. (See also http://blogs.msdn.com/florinlazar/archive/2005/05/17/418595.aspx)

  • Anonymous
    August 24, 2006
    hello,florinlazar. I have one question about Transaction. using (TransactionScope transScope = new TransactionScope()) //do something on database transScope.Complete(); } above code is the standard usage. my question is the lifecycle about dbconnection. we add some code nearby "//do something on database", meanwhile before transScope.Complete(), such as --- open a db connection , and insert one row, then close db connection. my question is --- is db connection really closed before transScope.Complete() ? let's don't consider the connection pool on the client.Thanks in advance.

  • Anonymous
    September 27, 2006
    Estos últimos días he estado investigando sobre el funcionamiento de System.Transactions y su relación

  • Anonymous
    October 03, 2006
    To: Vince That is a question for the System.Data folks. It also depends on what you mean by "really closed".

  • Anonymous
    February 10, 2007
    A key feature that targets performance in System.Transactions is the Promotable Single Phase Enlistment.

  • Anonymous
    June 16, 2009
    PingBack from http://fixmycrediteasily.info/story.php?id=16180