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

Brian Peasland wrote:

The whole thing is synchronized by a transaction manger, like in merge replication in SQL Server the merge manager does. Think: SQL Server writes all Transactions in a transaction log. You can roll back any transaction to set the whole database into the last state, and you can roll forward again. The transaction manager in MVTO does the same, always keeping an eye on all data, their versions, update /creation timestamps .... in SQL Server there are always hidden columns in every table, which you can't see. With ACCESS 2000 the same. Create Master/Slave database for merge replikation and you will notice, that 2 hidden columns are added. For MVTO you need even 3 more than that, one for the transaction number and one for the transaction timestamps, begin/end.

regards, Guido Stepken

> "Some" overhead is probably being way too lenient in this scheme,
> especially in a highly concurrent environment where hundreds or
> thousands of users are attempting to modify the same data. So if there
> are no locks, and User A reads data, User B updates the same data, and
> then User A goes to update the same data depending on what User A read
> originally, how is the whole thing syncronized? Does User B look at User
> A's timestamp (even though User A has yet to modify data)? What happens
> to User A's transaction. User B modified the data, does User A then get
> killed?
>
> Cheers,
> Brian
>
Received on Mon Aug 18 2003 - 17:36:38 CDT