So, would you use such a thing in a medical application where people are
making judgments on the data they are seeing and allow the database to
"decide" how to "merge" data in the same row. Of course, not, that would be
sheer foolishness. The machine can't merge the results in a meaningful way
without throwing out or ignoring the state the two (or more) people saw the
data in when they made their change.
Jim
"Guido Stepken" <stepken_at_little-idiot.de> wrote in message
news:bhr6ic$14q$05$1_at_news.t-online.com...
> Hi, Brian !
>
> No, you do not create new data. You time - shift all transaction, let
> them run, as if they are working alone (in reality they work on their
> own snapshot of database, thank MVCC) and then, before updating the
> database, you look at the timestamp of other transactions and at the
> timestamp of updates and rearrange all, as if a lock had been set.
> Afterwards, you can drop all changes on the snapshot, a clean up.
> There is some overhead, yes. But that equals by many times the blocks in
> SQL Server, caused by locks, blocking each other (no deadlocks).
>
> Read about MVTO, its magic...for many SQL programmers, maybe...
>
> regards, Guido Stepken
>
> Brian Peasland wrote:
> > Maybe I missed something, and I admit that I don't know that much about
> > MVTO. But when you modify data with MVTO, aren't you simply creating
> > *new* data? You aren't modifying *old* data. Instead, you are creating a
> > new version of the old data. Versioning uses different techniques than
> > the techniques required for maintaining transaction consistency in
> > non-versioned data. IMO, you can't use versioning and then say that
> > locks are not necessary. They may not be necessary in versioned data,
> > but they are necessary in non-versioned data if you want to maintain any
> > semblance of transaction control and consistency.
> >
> > Cheers,
> > Brian
>
Received on Mon Aug 18 2003 - 18:07:21 CDT
