ADO. NET Entity Framework beta 3 and Linq to SQL differ in cache Processing

The built-in caching function of Linq to SQL. to put it simply, when you query the data of a key, the engine of linq to SQL no longer sends SQL statements to the database. For example:

// The following is an example of using LinQ to SQL. context2 is an instance derived from System. Data. Linq. DataContext.
ErpLinQContextDataContext context2 = new ErpLinQContextDataContext ();
// SQL Server event probe intercepts SQL statement execution
// Exec sp_executesql n' select top 1 [t0]. [emp_id], [t0]. [fname], [t0]. [minit], [t0]. [lname],
// [T0]. [job_id], [t0]. [job_lvl], [t0]. [pub_id], [t0]. [hire_date]
// FROM [dbo]. [employee] AS [t0]
// WHERE [t0]. [emp_id] = @ p0 ', n' @ p0 varchar (9)', @ p0 = 'pma42628m'
Employee p3 = context2.employees. First <employee> (p => p. emp_id = "PMA42628M ");
// When I run the same query again, the query is no longer sent to the SQL Server.
Employee p4 = context2.employees. First <employee> (p => p. emp_id = "PMA42628M ");

In addition, the two instances are the same instance:

// The returned object is the same instance.
Bool b2 = object. ReferenceEquals (p3, p4); // = true;
P3.lname = "New Last Name ";
Bool b4 = (p4.lname = "New Last Name"); // = true;

Of course, if you use different Context instance queries, the cache function will be effective.

Well, let's take a look at ADO. NET Entity Framework beta 3:

// PubsEntites is the System. Data. Objects. ObjectContext derived object of ADO. NET Entity Framework.
PubsEntities context = new pubsEntities ();

// When the following statement is executed, the SQL Server event probe intercepts SQL Execution
// Select top 1 [Extent1]. [emp_id] AS [emp_id], [Extent1]. [fname] AS [fname], [Extent1]. [lname] AS [lname],
// [Extent1]. [hire_date] AS [hire_date], [Extent1]. [job_id] AS [job_id], [Extent1]. [pub_id] AS [pub_id]
// FROM [dbo]. [employee] AS [Extent1]
// Where n 'pma42628m' = [Extent1]. [emp_id]
Employee p1 = context. EmployeeSet. First <Employee> (p => p. EmployeeId = "PMA42628M ");

// SQL Server event probe finds that SQL is executed again
Employee p2 = context. EmployeeSet. First <Employee> (p => p. EmployeeId = "PMA42628M ");
// The test shows that although the ADO. NET Entity Framework executes two SQL statements, they return identical instances.
Bool b1 = object. ReferenceEquals (p1, p2); // = true;

The test result is that the ADO. NET Entity Framework (AEF) does not use the cache, but executes the SQL statement again. However, you must note that the two query instances are the same.
From the Context function, he must have the result of the last query. He does not use the cache. I can only think that AEF may be designed as a three-tier application, so he is worried that other processes will change the data, so he does not use the cache. when the data is not changed, I still use the original Instance. Is this correct idea?
Let's look at another code: // if data is updated using different contexts,
PubsEntities context4 = new pubsEntities ();
Employee p10 = context4.EmployeeSet. First <Employee> (p => p. EmployeeId = "PMA42628M ");
P10.LastName = "Context4 changed data ";
Context4.SaveChanges ();

// When the old context is queried again.
Employee p11 = context. EmployeeSet. First <Employee> (p => p. EmployeeId = "PMA42628M ");
B1 = object. ReferenceEquals (p1, p11); // = true why ??
B1 = (p11.LastName = "Context4 changed data"); // = false p11.LastName = "New Last Name"

Unbelievable, AEF re-executes the SQL statement, but with new changes, the old data is still returned. Is this a Bug?

I don't know who can explain this question? Of course, I also asked MS for this question, and their technicians have not yet answered it satisfactorily.