Re: Avoiding any locks in SQL Servers - read and understand....itsmagic.

> I know, my point of view is unpopular, but very well researched. Reed
> has invented this method of rearranging transactions (time - shifting)
> and updates (lost update problem) in that way, that no locking at all is
> necessary. I is like magic, programmers never ever have to care about
> concurrent write events any longer, because they are time - shifted and
> rearranged in a manner, as if a lock had been set. You can do this by
> putting all timestamps on raws and transactions into context and setting
> the data sets to that value, as if a lock had been set. You simulate the
> result of locks on datasets afterwards, as if locks had occurred.

Please educate me then. Without locks, and use "time shifting", then a user gets the data that has been changed most recently. What happens if the user starts his transaction before this data was changed and then accesses this data after another user changes it? Which time-shifted variation does the user see? The one when the user started their transaction or the one that was changed sometime after their transaction started. If it is the latter, then this can lead to the user using data that is "out of sync" with the start of their transaction. If it is the former, then how does the system keep its overhead low while maintaining all of these time versioned records all in a highly-concurrent environment?

Thanks,
Brian

-- 
===================================================================

Brian Peasland
dba_at_remove_spam.peasland.com

Remove the "remove_spam." from the email address to email me.


"I can give it to you cheap, quick, and good. Now pick two out of
 the three"