Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. Design and Architecture
  4. Pattern for handling an ADO.net transaction

Pattern for handling an ADO.net transaction

Scheduled Pinned Locked Moved Design and Architecture
questioncsharpregexlearning
3 Posts 2 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • P Offline
    P Offline
    PIEBALDconsult
    wrote on last edited by
    #1

    I've been using the following pattern with transactions for some time now, without problems.

    try
    {
    // begin transaction
    // do stuff
    // Commit
    }
    catch ( System.Exception err )
    {
    // log err
    // Rollback
    }

    I have been operating under the assumption that if Commit or Rollback is called for a non-existent transaction, then throwing an exception is the right thing to do. The Commit and Rollback in question are my methods that check for null and throw InvalidOperationException rather than NullReferenceException. But recently I've run into some problems. For some reason (which I still need to investigate further, but I have an idea) the Commit fails because the transaction doesn't exist, which means the Rollback will also fail. Having an exception thrown through the catch is, of course, nasty. I could change the methods to raise an event instead of throwing. I could filter the exception to log but not rollback on certain exceptions (like InvalidOperationException). Has anyone else had to deal with this situation? Does anyone have a better pattern for this?

    P 1 Reply Last reply
    0
    • P PIEBALDconsult

      I've been using the following pattern with transactions for some time now, without problems.

      try
      {
      // begin transaction
      // do stuff
      // Commit
      }
      catch ( System.Exception err )
      {
      // log err
      // Rollback
      }

      I have been operating under the assumption that if Commit or Rollback is called for a non-existent transaction, then throwing an exception is the right thing to do. The Commit and Rollback in question are my methods that check for null and throw InvalidOperationException rather than NullReferenceException. But recently I've run into some problems. For some reason (which I still need to investigate further, but I have an idea) the Commit fails because the transaction doesn't exist, which means the Rollback will also fail. Having an exception thrown through the catch is, of course, nasty. I could change the methods to raise an event instead of throwing. I could filter the exception to log but not rollback on certain exceptions (like InvalidOperationException). Has anyone else had to deal with this situation? Does anyone have a better pattern for this?

      P Offline
      P Offline
      Pete OHanlon
      wrote on last edited by
      #2

      Well, the transaction can easily be checked by looking at the transaction on your command, e.g

      if (myCommand.Transaction != null)
      {
      myCommand.Transaction.Commit();
      }

      Deja View - the feeling that you've seen this post before.

      My blog | My articles

      P 1 Reply Last reply
      0
      • P Pete OHanlon

        Well, the transaction can easily be checked by looking at the transaction on your command, e.g

        if (myCommand.Transaction != null)
        {
        myCommand.Transaction.Commit();
        }

        Deja View - the feeling that you've seen this post before.

        My blog | My articles

        P Offline
        P Offline
        PIEBALDconsult
        wrote on last edited by
        #3

        Yes, and I do, but if it is null, I throw InvalidOperationException, because I feel that the caller should know about it. I don't want to continue as if everything was okey-dokey. I check the same thing in my Rollback method as well, which is causing the trouble.

        1 Reply Last reply
        0
        Reply
        • Reply as topic
        Log in to reply
        • Oldest to Newest
        • Newest to Oldest
        • Most Votes


        • Login

        • Don't have an account? Register

        • Login or register to search.
        • First post
          Last post
        0
        • Categories
        • Recent
        • Tags
        • Popular
        • World
        • Users
        • Groups