How much overhead does 'Update Check' have for LINQ UPDATES

Question

I have a simple row that I edit using LINQ. It has about 30 columns, including a primary key numeric sequence.

When an UPDATE is performed through LINQ, the UPDATE s

Answer 1

We ran into this early on Stack Overflow. Every LINQ to SQL update verifies that the underlying fields haven't changed before writing an update. In other words, every update is "update the record only if this field equals, and this field equals, and this field equals"..

We decided most of the time we didn't care about pessimistic updates, and the only field that the update needs to check is the Id field.

So, what we did was set UpdateCheck="never" for every field except the Id in the dbml mapping file, like so:

<Type Name="Badge">
  <Column Name="Id" Type="System.Int32" DbType="Int NOT NULL IDENTITY"
      IsPrimaryKey="true" IsDbGenerated="true" CanBeNull="false" />
  <Column Name="Class" Type="System.Byte" DbType="TinyInt NOT NULL"
      CanBeNull="false" UpdateCheck="Never" />
  <Column Name="Name" Type="System.String" DbType="VarChar(50) NOT NULL" 
      CanBeNull="false" UpdateCheck="Never" />

I don't know if there is a way to do this programmatically or on the fly.

Answer 2

Your assertion that the overhead for the update check is negligible is correct. If there is an index (or primary key) that is satisfied by any part of the where clause, then that will be used. The cost for checking the other columns is negligible. You can confirm this by enabling the execution plan display in SQL management studio (or query analyzer for older versions of SQL Server) and run your update.

Long execution times is most likely caused by something else. Locking is a good candidate. If you can reproduce it, use SQL Profiler to find out what is going on.

Answer 3

Timestamp field certainly seemed to be the most elegant way of doing this. I HATE having to mess with individual field's properties - mainly so I can safely delete and re-add a table to my DBML file without having to worry about the consequences.

http://msdn.microsoft.com/en-us/library/bb470449.aspx

The SQL now generated for an UPDATE is :

exec sp_executesql N'UPDATE [dbo].[SiteVisit]
SET [TotalTimeOnSite] = @p2
WHERE ([SiteVisitId] = @p0) AND ([timestamp] = @p1)

and in the same transaction:

SELECT [t1].[timestamp]
FROM [dbo].[SiteVisit] AS [t1]
WHERE ((@@ROWCOUNT) > 0) AND ([t1].[SiteVisitId] = @p3)',N'@p0 int,@p1 timestamp,@p2 int,@p3 int',@p0=814109,@p1=0x0000000000269CB8,@p2=1199920,@p3=814109

It does an UPDATE, and then retrieves the new timestamp to send back to my client. I'm not sure i fully understand what @@ROWCOUNT > 0 means, but right now I dont really care :)

Answer 4

If you can modify the schema add a column of type rowversion. The latest LINQ to SQL sets the update check to Never for all columns. If you have a timestamp, it will use that as an optimistic lock check, and the system bumps it every time there is an update.

NOTE: this used to be the Timestamp data type as defined by SQL '92, but the implemented it without any time information so it was not compatible with any other standard system. Maybe that was intentional, who knows.

Answer 5

Personally, I like the simplicity of a single timestamp/row-version column; set this as the only column to be checked (IIRC, happens automatically for timestamp), and you're sorted - you should then get TSQL like:

exec sp_executesql N'UPDATE [dbo].[SiteVisit]
SET [TotalTimeOnSite] = @p2, [ContentActivatedTime] = @p3
WHERE ([SiteVisitId] = @p0) AND ([Timestamp] = @p1)

This relies on their not being concurrent (non-conflicting) updates to the same record; with a timestamp/row-version etc, any conflicting update will cause the second to abort, even if they updated different columns etc.