locked
Problems using WF, WCF,WS-Atomic Transactions and Entity Framework RRS feed

  • Question

  • In my current project we are developing a SOA app using WF that calls (using netpipe binding with transactionflow enabled) in a transaction to WCF services. This WCF services have all the domain logic and retreive or save changes using EF against a SQL Server 2008 R2 database. Of course this transactions are promoted to DTC ones and are shared by the wcf domains and commited by the WF. Frequently we see exceptions in our appfabric log: all of them refer to transactions. For instance: System.Data.SqlClient.SqlException: Transaction context in use by another session. System.Data.SqlClient.SqlException: Distributed transaction completed. Either enlist this session in a new transaction or the NULL transaction. I have seen the option to set Enlist=false in connection string, but this way the call to the wcf would not be binded to the transaction. The current connection string is : "Data Source=;Initial Catalog=;Integrated Security=True;MultipleActiveResultSets=True;Max Pool Size=1024" What can I do to avoid this issues in my scenario? Thanks in advance.
    http://pablocastilla.wordpress.com/
    Tuesday, September 6, 2011 10:39 AM

Answers

  • Hello Pablo,

    Thanks for your post.

    This problem is caused when both of the following occurs:

    • DTS enlists the package in a Distributed Transaction Coordinator (DTC) transaction.

      -and-
    • The first "SELECT * FROM <source_table> statement is not stopped when the enlist operation is triggered.

      NOTE: The package automatically performs this SELECT query on both the source and destination tables.

    Thus, the enlisting transaction is affected by a new system process ID (SPID).

    The workaround is:

    To work around this problem, do any one of the following:

    • Do not enlist the Data Pump in a transaction.
    • Transfer data by using Transact-SQL scripts rather than DTS. Moving data without transformation is much faster with a query.
    • Place the source and destination databases on different servers.

    And more, please check your permission on your server. And see this KB: http://support.microsoft.com/?scid=kb;en-us;279857&spid=2852&sid=150

     

    have a nice day,


    Jackie Sun [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.


    • Edited by Jackie-Sun Friday, September 9, 2011 6:58 AM
    • Marked as answer by Jackie-Sun Tuesday, September 13, 2011 8:54 AM
    Friday, September 9, 2011 6:57 AM

All replies

  •  
    Transaction context in use by another session.
     
    I looked this message up. From what I have read, this is a SQL server issue.
     
    Tuesday, September 6, 2011 2:27 PM
  • Hello Pablo,

    Thanks for your post.

    This problem is caused when both of the following occurs:

    • DTS enlists the package in a Distributed Transaction Coordinator (DTC) transaction.

      -and-
    • The first "SELECT * FROM <source_table> statement is not stopped when the enlist operation is triggered.

      NOTE: The package automatically performs this SELECT query on both the source and destination tables.

    Thus, the enlisting transaction is affected by a new system process ID (SPID).

    The workaround is:

    To work around this problem, do any one of the following:

    • Do not enlist the Data Pump in a transaction.
    • Transfer data by using Transact-SQL scripts rather than DTS. Moving data without transformation is much faster with a query.
    • Place the source and destination databases on different servers.

    And more, please check your permission on your server. And see this KB: http://support.microsoft.com/?scid=kb;en-us;279857&spid=2852&sid=150

     

    have a nice day,


    Jackie Sun [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.


    • Edited by Jackie-Sun Friday, September 9, 2011 6:58 AM
    • Marked as answer by Jackie-Sun Tuesday, September 13, 2011 8:54 AM
    Friday, September 9, 2011 6:57 AM