In LINQ-To-SQL, should I use NOLOCK to improve performance? -
our dba came information our linq queries creating many thousands of locks on database. developer on our team dug hanselman post possible solution our problem:
http://www.hanselman.com/blog/gettinglinqtosqlandlinqtoentitiestousenolock.aspx
scott provides 3 ways in linq setting nolock. 1) transactionscope (preferred), 2) sprocs, 3) context.executecommand
we news site 99% reads, 1% writes our major focus on speed of retrieval. nolock strategy our linq-to-sql queries?
what i'm trying understand why using nolock or isn't idea. there must lot of people our same goals: many fast reads, little no updates. if nolock obvious answer, why isn't default? why can't make default on context, instead of having set in every single data call?
is nolock best option many fast reads, few updates site?
update: in sql server 2005 , above, snapshot isolation better nolock? found http://msdn.microsoft.com/en-us/library/ms179599.aspx
which covers read committed snapshot. prevents write-block, doesn't return dirty data? should used 90% of time on nolock?
update 2: what's bothering me dry
the part that's bothering me in order implement either no-lock or snapshot pattern, have change on every linq-to-sql query method (except being used in updates). smells major violation of dry.
worth noting: read committed snapshot
(or @ least 2+ years ago) enough the site you're using.
Comments
Post a Comment