Re: Disk Blocks/pages, Consistent Reads, undo

From: markpapadakis <markpapadakis_at_gmail.com>
Date: Fri, 4 Jan 2008 07:28:47 -0800 (PST)
Message-ID: <8eeeab2a-9da6-4906-a62e-f580038df337@e6g2000prf.googlegroups.com>

On Jan 4, 2:41 pm, "Jonathan Lewis" <jonat..._at_jlcomp.demon.co.uk> wrote:
> "markpapadakis" <markpapada..._at_gmail.com> wrote in message
>
> news:6646154c-6de8-460e-a965-a30bbadbf581_at_x69g2000hsx.googlegroups.com...
>

>
>
> Mark,
>
> The transaction will only change the current version of the
> block. But it generates the read consistent version of the
> block to make sure that the data it wants to change in the
> current version is identical to the data as it was when the
> transaction started.
>
> For example:
> I want to change col1 from X to Z in something that is
> current row 3 of the block (update where co1 = 'X')
>
> I create the read-consistent version of the block, and
> find that the same row was there when my transaction
> started - but the value of col1 was then 'Y'.
>
> So I can't update it because when my transaction started
> it wasn't a row that I was supposed to update.
>
> For more details on how messy and expensive this can get
> do a search on AskTom for "write consistency"

Thank you Jonathan,

I think I understand consistent reads works, in general. What puzzles me, still, can perhaps be better demonstrated with the following examples/scenarios:

TrA: Begins
TrB: Begins
TrB: Updates a row ( which is row #3 in block #100 ) and locks it
TrA: Wishes to update row #4 on the same block(block #100). So it

fetches the block. Because of the consistent read properties, the block data it will fetch will be == block data when TrA began.
It updates the value, set a lock on row #4 and Commits. TrB: Commits the data on disk. That data will hold the updated row#3 value, but will overwrite #row4 updated ( by TrA) data.

Another example:

TrA: Begins
TrB: Begins
TrA: Updates a row ( row#3 on block #100) and before it does so, it

locks it
TrB: wishes to update the same row (row#3 on block #100) and before it does so it attempts to lock it. Because
of read consistent read properties, TrB will fetch the block as it was when TrB began, whereas there is no lock on row#3 So itself sets a lock on row#3.
It seem as for this example, it shouldn't rely on a consistent read but get the latest data for that block, for the on-block row-level locking
to work.

Thank you,
MarkP Received on Fri Jan 04 2008 - 09:28:47 CST