use Perl

• I would imagine something like this: (Score:1)

  by Adrian (66)

  Fred and Mary start with:

  1 A
  2 B
  3 C

  Fred starts a transaction and updates the first two rows so the table that looks like:

  1 X
  2 Y
  3 C

  In the mean time Mary has started and finished a transaction that updates the third row:

  1 A
  2 B
  3 Z

  which means that Fred is seeing the "old" version of row three, and the table as a whole reflects something that will never have existed in the database.

  Make sense?
  • Re:I would imagine something like this: (Score:2)

    by Ovid (2709) on 2007.09.04 9:43 (#57417) Homepage Journal

    Oh! I replied to Aristotle without thinking too carefully about your reply. I can see how this could occur, but it's problematic because then things aren't atomic. If you take actions based upon this, you can still corrupt your data. You update row 3 because 'C' is there, but it's really not. Now you have a race condition because consistent reads aren't. Or did I misunderstand something?

    Reply to This

    Parent

    • Re: (Score:1)

      by Guss (8124)

      You can't talk about atomic operations and transactions at the same time - its kind of contradictory. Atomic operations mean that the database is either in a state before the operation or in a state after the operation, and never in between. But transaction means that you can group several actions and execute them so that the database reflect the changes only after the execution of all actions - the transaction can't be atomic in the sense that from inside it you can see the intermediate state. In the exam
    • Re: (Score:1)

      by perrin (4270)

      In most applications, this is allowed because it improves concurrency so much. If you really need to prevent it, you can set the isolation level to SERIALIZABLE, and then additional locks will be used so that you can't modify data that another transaction is currently looking at and potentially preparing to modify.