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

> Ok, maybe that's in the standard and I don't argue what *is*.
> But wouldn't a "first commit wins" policy mean that short transactions
> can starve out longer running ones by forcing repeated rollbacks and
> retries?
>
> Do I see a reason for locks here?

Absolutely! Transactions have different lifetimes and do different things. One transaction may modify one row of data in one table. Another transaction may modify thousands of rows of data from many, many tables. It's all about maintaing transaction consistency in the ACID model with a high degree of concurrency. Remember that the "I" in ACID means Isolated. How does a transaction appear to be isolated, or alone in the system, if another transaction that commits first kills the transaction? Isolation is thrown out the window.

Cheers,
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"