LINQ to SQL combining read uncommitted and read committed

I'd like to use LINQ to SQL as the data layer for an application. Optimistic concurrency seems like it would work, but I'd like to be over-optimistic and not bother with any locking (e.g. ReadUncommitted a.k.a. WITH (NOLOCK)) until I get to SubmitChanges(), at which point I think it's OK to use ReadCommitted.

Does this sound like madness? Is it better to use two disjunct TransactionScope objects (one for reading with ReadUncommitted, followed by a second for submitting changes with ReadCommitted), or is there some nicer way I can raise the isolation level immediately before submitting changes开发者_StackOverflow?

---

ReadCommitted or ReadUncommitted does not matter on a SubmitChanges() because it is a write, not a read. No matter what the isolation level, an update always acquires a lock and respects existing locks. It has to, that is the main purpose of locks.

Of course, by updating uncommitted data you run the risk that the record does not even still exist to be updated, but that was the risk you accepted when deciding to be optimistic.