title: How to manage the scope of db context in .NET Core when SaveChanges() fails
body: <p>We have a .NET Core console app that is triggered by an Azure service bus queue. My understanding is that the default lifetime of the DbContext via DI is <code>Scoped</code> and that it's recommended to let DI and the framework manage the lifetime instead of using <code>using</code> statements. However, we have the following case where we call <code>SaveChanges()</code>, it fails, so we try to call it again to write a log to the db. What's the recommended approach here? It feels weird to use <code>using</code> when the context is injected by DI to the calling class.</p>
  
  <pre><code>try
  {
      db.Add(new MyEntity());
      db.SaveChanges();
  }
  catch (Exception ex) // a constraint is violated
  {
      db.Add(new LogEntity("Unable to save MyEntity"));
      db.SaveChanges(); // this fails because MyEntity is still in scope of the context
  }
  </code></pre>