Trade-offs between longer data context or transaction outside of context?
<p>I am writing a Web API Rest service that does operations on a distinct set of entities. I have broken them down like this:</p>

<pre><code>        db = new DBEntities();

        using (var dbContextTransaction = db.Database.BeginTransaction())
        {
            try
            {
                ProcessClient();
                ProcessClientPerson();
                ProcessGuardian();
                ProcessAddress();
                ProcessEmail();
                ProcessPhones();
                ProcessChildren();

                dbContextTransaction.Commit();
            }
            catch (Exception ex)
            {
                dbContextTransaction.Rollback();

            etc.
</code></pre>

<p>Following the advice that data contexts should live as short as possible, each of the methods creates its own data context, calls SaveChanges(), and disposes of it at the end:</p>

<pre><code>  private ProcessClient()
  {
        db = new DBEntities();
        ....
</code></pre>

<p>This obviously does not work - a transaction context created this way is tied to the data context. If something goes wrong in one of the entity operations, only that operation is rolled back (implicitly), but the overarching transaction is not.</p>

<p>I found this <a href="https://msdn.microsoft.com/en-us/data/dn456843.aspx#existing" rel="nofollow">approach for creating a transaction outside of EF</a>, but I am wondering if I should follow it or if I should just let my data context live for the duration of the transaction and keep the transaction inside of EF!?</p>

<p>I am not looking for an opinion, but for data around stability, performance, etc.</p>