How/When Sql server updates the record timestamp value, if I have a transaction with multiple CRUD operations - entity-framework

Question

I am working on an asp.net mvc web application and I am using an entity framework to map my tables into model classes.
I have the model class representing VMS:-
public partial class TMSVirtualMachine
{
public int TMSVirtualMachineID { get; set; }
public int ServerID { get; set; }
public int RoleID { get; set; }
public Nullable<int> BackUpStatusID { get; set; }
public Nullable<int> StatusID { get; set; }
public Nullable<int> MonitoreID { get; set; }
public Nullable<decimal> TotalStorage { get; set; }
public string Comment { get; set; }
public byte[] timestamp { get; set; }
public Nullable<long> IT360SiteID { get; set; }
public virtual TMSServer TMSServer { get; set; }
//cde goes here…
}
And I have the following repository method , which will move all the current server;s VMS to another server, by changing the VM's ServerID as follow:-
public int changeVMsServer(AssignVMsToServer s, string username)
{
int count = 0;
var currentvms = tms.TMSVirtualMachines.Where(a => a.ServerID == s.serverIDForm);
foreach (var v in currentvms)
{
v.ServerID = s.serverIDTo;
tms.Entry(v).State = EntityState.Modified;
count++;
}
SaveChanges();
return count;
}
Currently if two users call the above method at the same time one of them will get a DBUpdateConcurrentException, since the timestamp for a VM when trying to save it, will be different than when the VM was retrieved.
My question is basically how SQL server 2008 r2 manage the timestamp column. Let take the following scenario:-
First user retrieve 5 VMs, then generate 5 SQL update commands and save.
Second user retrieve 5 VMs, then generate 5 SQL update , and when trying to save , EF will detect that the timestamp has been changed for atleast one VM and raise a DBUPdateException.
Now when the first user perform the 5 SQL updates operation , his work will not be saved until the 5 update operation successed , since the 5 update operations are wrapped in a single trancaction.
Q1) So when will sql server 2008 r2 changed the timestamp column for the 5 servers , when the transaction is completed ?, or when a single update operation is saved ?, and if the transaction failed will sql server return the old timestamp value ?
Sorry for the long email, but I tried searching for a clear answer , but could not reach a final conclusion.

Answer 1

MSDN documentation on timestamp is quite clear:
Is a data type that exposes automatically generated, unique binary numbers within a database. timestamp is generally used as a mechanism for version-stamping table rows. The storage size is 8 bytes. The timestamp data type is just an incrementing number and does not preserve a date or a time. To record a date or time, use a datetime data type.
...
You can use the timestamp column of a row to easily determine whether any value in the row has changed since the last time it was read. If any change is made to the row, the timestamp value is updated.
So, it's clear that the timestamp is modified when the row changes.
EF will use this column for concurrency checking: if an app reads a row, modifies it and try to save the changes in the DB and the timestamp changed since it was read, then the concurrency exception is thrown.
As to the transaction, what you're missing is the "transaction isolation" concept. The timestamp column changes when a change is made to the row. But what happens if a different connection tries to read this row depends on the isolation level: the row can be locked until the transaction finishes (so the other connection will have to wait until that moment), or the other connection can read the new uncomitted value or it can read the old value. It depends on the isolation level.
By default in SQL Server the isolation level is:
READ COMMITTED
Specifies that statements cannot read data that has been modified but not committed by other transactions. This prevents dirty reads. Data can be changed by other transactions between individual statements within the current transaction, resulting in nonrepeatable reads or phantom data. This option is the SQL Server default.