CODEWITHSUNDEEP
c#multithreadingentity-frameworkdbcontext
Kristian Nissen
Kristian Nissen

Reputation: 1184

Multiple instances of EF 5.0 DbContext Concurrency

I'm trying to simulate a scenario with multiple seperate applications accessing my database. The way i am doing this is creating 10 different threads, that makes some concurrent transactions and such. Each thread has an instance of my DbContext.

The problem is, the DbContexts do not know about updates in the other instances. So my question is this, how do i make sure that my DbContexts does not contain inconsistent data?

Upvotes: 1

Views: 476

Answers (2)

Taugenichts
Taugenichts

Reputation: 1365

The issue is they cache the database tables they make calls to. You would have to create a new dbContext whenever there is an update to a database table that is already cached.

You could also try messing around with the caching settings to make them timeout sooner, so the updated results will be reflected in the other dbContexts sooner (test enabling and disabling lazy loading for example). I have honestly never tried playing with them too much; I have always just made a new dbContext and that has worked for me.

Upvotes: 1

Eric J.
Eric J.

Reputation: 150108

You risk some level of inconsistent data if you use any isolation level other than Serializable. Serializable is rather expensive in terms of performance and is only used in very specific situations.

SERIALIZABLE Specifies the following: Statements cannot read data that has been modified but not yet committed by other transactions. No other transactions can modify data that has been read by the current transaction until the current transaction completes. Other transactions cannot insert new rows with key values that would fall in the range of keys read by any statements in the current transaction until the current transaction completes. Range locks are placed in the range of key values that match the search conditions of each statement executed in a transaction. This blocks other transactions from updating or inserting any rows that would qualify for any of the statements executed by the current transaction. This means that if any of the statements in a transaction are executed a second time, they will read the same set of rows. The range locks are held until the transaction completes. This is the most restrictive of the isolation levels because it locks entire ranges of keys and holds the locks until the transaction completes. Because concurrency is lower, use this option only when necessary. This option has the same effect as setting HOLDLOCK on all tables in all SELECT statements in a transaction.

Snapshot isolation will also prevent dirty, non-repeatable and phantom reads but does not prevent Thread 1 and Thread 2 from observing different data during overlapping time periods.

SNAPSHOT Specifies that data read by any statement in a transaction will be the transactionally consistent version of the data that existed at the start of the transaction. The transaction can only recognize data modifications that were committed before the start of the transaction. Data modifications made by other transactions after the start of the current transaction are not visible to statements executing in the current transaction. The effect is as if the statements in a transaction get a snapshot of the committed data as it existed at the start of the transaction.

This is a rather broad topic. A good starting point is

http://technet.microsoft.com/en-us/library/ms189122(v=sql.105).aspx

Transactions specify an isolation level that defines the degree to which one transaction must be isolated from resource or data modifications made by other transactions. Isolation levels are described in terms of which concurrency side-effects, such as dirty reads or phantom reads, are allowed.

Upvotes: 1

Related Questions