entity framework and dirty reads

I have Entity Framework (.NET 4.0) going against SQL Server 2008. The database is (theoretically) getting updated during business hours -- delete, then insert, all through a transaction. Practically, it's not going to happen that often. But, I need to make sure I can always read data in the database. The application I'm writing will never do any types of writes to the data -- read-only.

If I do a dirty read, I can always access the data; the worst that happens is I get old data (which is acceptable). However, can I tell Entity Framework to always use dirty reads? Are there performance or data integrity issues I need to worry about if I set up EF this way? Or should I take a step back and see about rewriting the process that's 开发者_如何学JAVAdoing the delete/insert process?

---

TransactionScope is your friend: Entity Framework with NOLOCK

---

Don't use dirty reads. "The worst" isn't that you see old data. The worst is that you see uncommitted data. Stack Overflow uses snapshots rather than dirty reads to solve this problem. That's what I'd do, too.

---

From the previous link, I found this, which also answers the question.

http://www.hanselman.com/blog/GettingLINQToSQLAndLINQToEntitiesToUseNOLOCK.aspx