Re: Rowlock v. optimistic concurrency
- From: Erland Sommarskog <esquel@xxxxxxxxxxxxx>
- Date: Tue, 5 Feb 2008 22:22:37 +0000 (UTC)
(Roger.Noreply@xxxxxxxxx) writes:
Sql-Server 2000, 2005.
A report fetches a lot of rows using the "WITH (ROWLOCK)" syntax (the
sql is generated on the fly by a tool and not easily changeable).
SELECT col1, col2 FROM mytab WITH (ROWLOCK) WHERE ...."
The select-clause runs for several minutes.
Another user fetches one of those rows and tries to update it. The
result is a lock timeout.
Note that lock timeouts are by default off in SQL Server.
I suppose that the long running select-clause has put a shared lock on
the rows and the updater (exclusive-lock) will have to wait for the
long-running select and so the lock timeout is expiring.
There are two possible reasons:
1) The client has not picked up all rows, that the query has selected.
As long as the rows are unconsumed, the lock will linger.
2) The query needs to scan one or more indexes. In this case row locks
be row locks on all rows in the index.
The latter is the more likely explanation. To veridfy this, you would
need to analyse the blocking situation, to see which locks the updater
fails to get.
Are all those rows "shared locked" until all are fetched?
Would there be any change if the "WITH (ROWLOCK)" is removed, isn't
although "shared lock" the default behaviour?
If the hint prevents escalation to a table lock, removing the hint
could cut the response time a bit. But the most likely it would not
have any effect at all.
The "WITH (NOLOCK)" would probably help?
Yes. However, since you would read uncommitted data, the report may
produce inconsistent or incorrect results.
What about the definition of optimistic concurrency, shouldn't all
select-clauses contain "WITH (NOLOCK)" to allow an optimistic
concurrency scenario?
NOLOCK has nothing to do with optimistic concurrency. Usually whan you talk
about optimistic concurrency you mean techniques where you detect simul-
taneous updates without keeping rows locked.
Putting NOLOCK on all SELECT is not a good idea at all. Sure, a report
that is used to give you trends or be input for marketing people can
probably work with NOLOCK, since it does not have to be wholly accurate.
But if it is a financial report telling your standings, NOLOCK is out
of the question.
--
Erland Sommarskog, SQL Server MVP, esquel@xxxxxxxxxxxxx
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx
.
- Follow-Ups:
- Re: Rowlock v. optimistic concurrency
- From: Roger . Noreply
- Re: Rowlock v. optimistic concurrency
- References:
- Rowlock v. optimistic concurrency
- From: Roger . Noreply
- Rowlock v. optimistic concurrency
- Prev by Date: Re: Crosstabbing (or rotating) a sql table
- Next by Date: Simplest way to write a boolean expression in the SELECT clause?
- Previous by thread: Rowlock v. optimistic concurrency
- Next by thread: Re: Rowlock v. optimistic concurrency
- Index(es):
Relevant Pages
|
|