Question

In reading an article on N-Tiered Applications, I came across information regarding concurrency tokens and change tracking information:

Another important concept to understand is that while the
default-generated entities support serialization, their
change-tracking information is stored in the ObjectStateManager (a
part of the ObjectContext), which does not support serialization.

My question is three-fold:

1. Is there the same thing when using DbContext?
2. If the only interaction with the database is in a Repository class within a using statement, does closing the database connection when the program leaves the using statement get rid of any option for change tracking?
3. Can this be leveraged as/with a Concurrency Token?

Answer 1

1. Yes. DbContext is just wrapper around ObjectContext and it exposes change tracking information through ChangeTracker property (returns DbChangeTracker) and for particular entity through calling Entry method (returns DbEntityEntry<T>).
2. Yes. Closing context will remove all change tracking information.
3. Concurrency token and change tracking are two completely different concepts. Change tracking tells context what operations it has to execute on database when you call SaveChanges. It tracks changes you did on your entities since you loaded them into current context instance. Concurrency token resolves optimistic concurrency in the database => it validates that another process / thread / user / context instance didn’t change the same record your context is going to modify during SaveChanges.