Question

I've an event-driven app that has recently started using SQL Express 2008 (instead of Std version) in dev and test to store the current state of a state machine. After moving to SQL Express, we started seeing a discrepancy between the order in which we write to the database (using LINQ to SQL) and the order in which SQL Express Profiler reports the data going into the database.

We log the data using Log4Net, and the log entries show the incoming events occur in the correct order and we must have processed them in the correct order. We've also found when profiling SQL express, that the data is being written out of order. The effect is that when subsequent events come in (about 500ms after calling SubmitChanges() on the LINQ data context), the DB writes have not (yet?) been committed, so the state models think we are in an invalid state, and don't transition properly. The end result is chaos.

For what it's worth, I don't see this in SQL Server 2008 Standard, so I'm wondering if this is a problem with SQL express? Have you seen similar problems to this?

I'm assuming that it's not a problem with the profiler, since we do actually have a transition problem with some state transitions, so the profiler does seem to agree with observed results.

Regards,

Andrew Matthews

Was it helpful?

Solution

When you say you have processed them in the right order do you mean the order in which you told LINQ to SQL to do something? The reason is that LINQ to SQL internally reorders the operations.

What are you logging? The LINQ to SQL datacontext log property?

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top