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
CODE PROJECT For Those Who Code
  • Home
  • Articles
  • FAQ
Community
  1. Home
  2. Database & SysAdmin
  3. Database
  4. How do I make a transaction an "atomic" operation? (SQL Server 2005) [modified]

How do I make a transaction an "atomic" operation? (SQL Server 2005) [modified]

Scheduled Pinned Locked Moved Database
databasequestioncsharpsql-serversysadmin
27 Posts 9 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.
  • L Luc Pattyn

    and you probably need more time to get used to the new monitor... :)

    Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]


    I only read code that is properly indented, and rendered in a non-proportional font; hint: use PRE tags in forum messages


    R Offline
    R Offline
    Roger Wright
    wrote on last edited by
    #21

    That's at home, and yes, it's taking some getting used to. :laugh: I never realized just how wrong it looks to have square cards for solitaire! Worse, I think a recent Windows Update must have made it harder; I haven't won a game in days!!!

    "A Journey of a Thousand Rest Stops Begins with a Single Movement"

    1 Reply Last reply
    0
    • X Xiangyang Liu

      What I want in the transaction: 1. Check if a database record's status field is "pending". 2. If it is, then set status field to "processing", then process it. Otherwise, don't do anything. 3. After processing, set the status field to "processed". If the above code is in a "critical section", then I can guarantee only one client is processing a record. I thought putting the code within a transaction will solve the problem. Apparently not.

      My .NET Business Application Framework My Home Page My Younger Son & His "PET"

      C Offline
      C Offline
      Chris Meech
      wrote on last edited by
      #22

      :doh: I think I just heard the '70s call and they want the term batch processing brought back. :cool:

      Chris Meech I am Canadian. [heard in a local bar] In theory there is no difference between theory and practice. In practice there is. [Yogi Berra]

      X 1 Reply Last reply
      0
      • X Xiangyang Liu

        Roger Wright wrote:

        Would it help to set the Isolation Level for the transaction to Serializable?

        That's exactly what was suggested by our DBA. Howver, there is still a chance to screw up. Here is what is within the transaction: 1. Check if the record's status field is "pending". 2. If it is, then set it to "processing" and process it, otherwise return. By reading the documentation about "serializable", it seems possible for two different clients to find the status field to be "pending", and each setting it to "processing" and each processing the same record. However, setting isolation level to "seriablizable" greatly reduced the chance of two clients processing the same record. Let me know if I am wrong on this. Thanks.

        My .NET Business Application Framework My Home Page My Younger Son & His "PET"

        J Offline
        J Offline
        Jorgen Sigvardsson
        wrote on last edited by
        #23

        I suspect an UPDATE could be of help, since they are atomic, much like an interlocked increment.

        UPDATE table SET status = 'processing' WHERE status = 'pending' AND PrimaryKey = @value;
        if row count > 0
        -- Do the processing
        else
        -- Some other client is processing...
        end if

        -- Kein Mitleid Für Die Mehrheit

        X R 2 Replies Last reply
        0
        • C Chris Meech

          :doh: I think I just heard the '70s call and they want the term batch processing brought back. :cool:

          Chris Meech I am Canadian. [heard in a local bar] In theory there is no difference between theory and practice. In practice there is. [Yogi Berra]

          X Offline
          X Offline
          Xiangyang Liu
          wrote on last edited by
          #24

          Chris Meech wrote:

          they want the term batch processing brought back.

          I hardly noticed they were gone. When did that happen? For how long? :-D

          My .NET Business Application Framework My Home Page My Younger Son & His "PET"

          1 Reply Last reply
          0
          • J Jorgen Sigvardsson

            I suspect an UPDATE could be of help, since they are atomic, much like an interlocked increment.

            UPDATE table SET status = 'processing' WHERE status = 'pending' AND PrimaryKey = @value;
            if row count > 0
            -- Do the processing
            else
            -- Some other client is processing...
            end if

            -- Kein Mitleid Für Die Mehrheit

            X Offline
            X Offline
            Xiangyang Liu
            wrote on last edited by
            #25

            Ok, this could be another solution, and simpler, too. Thanks.

            My .NET Business Application Framework My Home Page My Younger Son & His "PET"

            1 Reply Last reply
            0
            • X Xiangyang Liu

              Roger Wright wrote:

              Would it help to set the Isolation Level for the transaction to Serializable?

              That's exactly what was suggested by our DBA. Howver, there is still a chance to screw up. Here is what is within the transaction: 1. Check if the record's status field is "pending". 2. If it is, then set it to "processing" and process it, otherwise return. By reading the documentation about "serializable", it seems possible for two different clients to find the status field to be "pending", and each setting it to "processing" and each processing the same record. However, setting isolation level to "seriablizable" greatly reduced the chance of two clients processing the same record. Let me know if I am wrong on this. Thanks.

              My .NET Business Application Framework My Home Page My Younger Son & His "PET"

              R Offline
              R Offline
              Roger Wright
              wrote on last edited by
              #26

              According to MSDN,

              Statements cannot read data that has been modified but not yet committed by other transactions.

              No other transactions can modify data that has been read by the current transaction until the current transaction completes.

              Other transactions cannot insert new rows with key values that would fall in the range of keys read by any statements in the current transaction until the current transaction completes.

              It sounds to me like you would be fairly safe with this setting. Certainly it would be safer than the default.

              "A Journey of a Thousand Rest Stops Begins with a Single Movement"

              1 Reply Last reply
              0
              • J Jorgen Sigvardsson

                I suspect an UPDATE could be of help, since they are atomic, much like an interlocked increment.

                UPDATE table SET status = 'processing' WHERE status = 'pending' AND PrimaryKey = @value;
                if row count > 0
                -- Do the processing
                else
                -- Some other client is processing...
                end if

                -- Kein Mitleid Für Die Mehrheit

                R Offline
                R Offline
                Roger Wright
                wrote on last edited by
                #27

                Yup, much easier! :-D

                "A Journey of a Thousand Rest Stops Begins with a Single Movement"

                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