Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

What does this "consistent read" statement mean? 3 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

  • a SELECT will see the latest version of the updated rows, but it might also see older versions of any rows.

    I think the key is the “any”, and what they are trying to say is that if you start a transaction, you will only see rows as they were at the time of the transaction start, plus newer data in rows you updated since.

    If other users simultaneously update the same table, the anomaly means that you may see the table in a state that never existed in the database.

    I think what this is trying to say is that you only commit the rows you changed, and by the time you commit them, the old rows you aren’t committing may have changed, so the combination of rows-as-of-start-of-transaction and rows-updated-during-transaction that you see from within the transaction likely never actually exists on disk.

    It is very confusingly written, but I’m not sure how it could have been made easier to understand. Human brains are only marginally capable of grasping temporal event flows, and we get really confused when we have to think about timelines in multiple alternate realities. (I think Damian Conway may have recently said some stuff along those lines…)

    • Here's the problem I have:

      The exception to this rule is that the query sees the changes made by earlier statements within the same transaction.

      So the exception occurs withing a transaction.

      If other users simultaneously update the same table, the anomaly means that you may see the table in a state that never existed in the database.

      So the exception occurs within a transaction. The anomaly occurs when several uses update the same table. How does that happen within a single transaction?

      • It doesn’t happen in a single transaction.

        You see the updates you made, plus the rows you didn’t touch in whatever state they were when you started. This is within the transaction.

        By the time you commit your changes, the rows you didn’t change may differ from what they were when you started the transaction. Obviously, if they differ, this must be because other users updated the table alongside your transaction.

        So the particular world that you were seeing from within the transaction (

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.