Optimistic concurrency not verified in Delete operation

[Alexander]

Let's assume REST service scenario (MVC) with Domain model & context, and MS SQL table like

CREATE TABLE Leagues (
    LeagueId int IDENTITY(1,1) NOT NULL PRIMARY KEY,
    LeagueName nvarchar(512) NOT NULL,
    StateProvince varchar(3) NOT NULL,
    CountryCode varchar(3) NOT NULL,
    RV timestamp NOT NULL
)

// LeagueController.cs
public class LeagueController : Controller {
   DataContext dc = null;

  public LeagueController() {
    dc = new DerbyContext();
  }
  // ...
  // UPDATE - works perfectly: "... WHERE [LeagueId] = ? AND [RV] = ?"
[HttpPost]
public ActionResult Edit(int id, FormCollection collection) {
  League league = new League() {
    LeagueId = id,
    LeagueName = String.IsNullOrEmpty(collection["LeagueName"]) ? null : collection["LeagueName"],
    StateProvince = String.IsNullOrEmpty(collection["StateProvince"]) ? null : collection["StateProvince"],
    CountryCode = String.IsNullOrEmpty(collection["CountryCode"]) ? null : collection["CountryCode"],
    RV = Int64.Parse(collection["RV"])
  };
  league = dc.AttachCopy<League>(league);
  dc.SaveChanges();
// ...
}

// DELETE - does NOT take RV field into account: "... WHERE [LeagueId] = ?"
[HttpPost]
public ActionResult Delete(int id, FormCollection collection) {
  League league = new League() {
    LeagueId = id,
    RV = Int64.Parse(collection["RV"])
  };
  league = dc.AttachCopy<League>(league);
  dc.Delete(league);
  dc.SaveChanges();
  //...
}

and the record gets deleted despite it has been modified in another app

[Simeon Simeonov]

Hi Alexander,

Thank you for contacting us.

You are right, no optimistic concurrency verification is performed when a tracked object is deleted from the context. This is expected behavior for DataAccess.

If you want this check to be performed in your case you could get the object from the context by Id and check explicitly if  RV value in the database is equal to the RV value from the FormCollection object.

Regards,
Simeon Simeonov
Telerik

 

 

[Alexander]

Hi, Simeon,

Thank you, I got it. I agree that in some scenarios (for ex. REST delete by URI without POST data) row version might not be accessible.
But, for example, MS Entity Framework does make a rowversion field check during delete without preliminary select,  and even it does not validate non-nullable fields that has not been assigned (only ID and RV is enough).
(NHibernate does not, or I haven't managed)

[Simeon Simeonov]

Hi Alexander,

Yes, this is a design decision in Telerik DataAccess, one that I am afraid we must abide with.
If you need any further assistance implementing your own concurrency check mechanism before doing the delete, do not hesitate to contact us with your questions.

Regards,
Simeon Simeonov
Telerik