We're using adapter and I'm wondering about what approach you would recommend when spanning transactions across multiple sequential methods. Let's use the following example:

public class MyClass
{
     public void BigMethod()
     {
          SmallMethodA();
          SmallMethodB();
          SmallMethodC();
     }

     private void SmallMethodA()
     {
          ///Do Some Stuff
     }

     private void SmallMethodB()
     {
          ///Do Some More Stuff
     }

     private void SmallMethodC()
     {
          ///Do Some Other Stuff
     }

}

...if I wanted to perform all within one transaction, would it be best to modify the code to be like this:

public void BigMethod()
     {
          DataAccessAdapter da = new DataAccessAdapter();
          da.StartTransaction(IsolationLevel.ReadCommitted,"TranName");
          try
          {
               SmallMethodA(da);
               SmallMethodB(da);
               SmallMethodC(da);
               da.Commit();
          }
          catch
          {
               da.Rollback();
               throw
          }
          finally
          {
               da.dispose();
          }
     }

     private void SmallMethodA(DataAccessAdapter da)
     {
          ///Do Some Stuff
     }

     private void SmallMethodB(DataAccessAdapter da)
     {
          ///Do Some More Stuff
     }

     private void SmallMethodC(DataAccessAdapter da)
     {
          ///Do Some Other Stuff
     }

Besides the connection being open during that time, are there other issues I need to consider? Do the rules change if I use static methods?

Sounds fine to me, nothing special to consider if you use static methods. The only possible issue is in the fact that line

da.StartTransaction(IsolationLevel.ReadCommitted,"TranName");

lies outside try catch and your adapter won't be disposed if an exception happens there, so this should be better:

using (DataAccessAdapter da = new DataAccessAdapter()) { da.StartTransaction(IsolationLevel.ReadCommitted,"TranName"); try { SmallMethodA(da); SmallMethodB(da); SmallMethodC(da); da.Commit(); } catch { da.Rollback(); throw } }

NickD wrote:

We're using adapter and I'm wondering about what approach you would recommend when spanning transactions across multiple sequential methods. Let's use the following example:

public class MyClass
{
     public void BigMethod()
     {
          SmallMethodA();
          SmallMethodB();
          SmallMethodC();
     }

     private void SmallMethodA()
     {
          ///Do Some Stuff
     }

     private void SmallMethodB()
     {
          ///Do Some More Stuff
     }

     private void SmallMethodC()
     {
          ///Do Some Other Stuff
     }

}

...if I wanted to perform all within one transaction, would it be best to modify the code to be like this:

public void BigMethod()
     {
          DataAccessAdapter da = new DataAccessAdapter();
          da.StartTransaction(IsolationLevel.ReadCommitted,"TranName");
          try
          {
               SmallMethodA(da);
               SmallMethodB(da);
               SmallMethodC(da);
               da.Commit();
          }
          catch
          {
               da.Rollback();
               throw
          }
          finally
          {
               da.dispose();
          }
     }

     private void SmallMethodA(DataAccessAdapter da)
     {
          ///Do Some Stuff
     }

     private void SmallMethodB(DataAccessAdapter da)
     {
          ///Do Some More Stuff
     }

     private void SmallMethodC(DataAccessAdapter da)
     {
          ///Do Some Other Stuff
     }

Besides the connection being open during that time, are there other issues I need to consider? Do the rules change if I use static methods?

I would recommend abstracting a class that all your business components inherit from that contains common functionality and contains the data access adapter. this way, your methods signatures do not have to be cluttered. Of course you could also make it a class level variable, but i would still opt for the base class. Also, I would think about exposing internal constructors accepting data access adapter instances when you need a transaction to span multiple business components.