LINQ Caching Objects

[Craig Wagner]

I've read in several places on the internet that if you make the same call to
LINQ repeatedly (without refreshing or re-creating the datacontext) it will
always return an object with the same values. I've seen this myself. I
created a WinForm application, issued a LINQ query, used SQL Server
Management Studio to change some values in the table, issued the LINQ query
again, and did not see the changes I'd made through SSMS. Fair enough.

What has me curious is that when I ran Profiler and did the same thing, I
saw SELECT statements being sent to the database for the second and
subsequent calls. So what I don't understand is why LINQ is querying the
database and apparently ignoring what it sends back?

Can anyone explain this seemingly inconsistent behavior or point me to an
article? I've been unsuccessful in finding an answer.

 

[Cowboy \(Gregory A. Beamer\)]

I believe LINQ is ensuring that the data has not changed, but I do not have
time to confirm that theory right now.

--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA

Subscribe to my blog
http://gregorybeamer.spaces.live.com/lists/feed.rss

or just read it:
http://gregorybeamer.spaces.live.com/

*************************************************
| Think outside the box!
|
*************************************************

 

[Marc Gravell]

Once it has the identity/primary key data, it compares that to the
internal list held by the context; this ensures that the context only
sees *one* instance of "Customer 20"; apart from memory, this also
ensures that you can only change-set for a single entity in the same
data-context. Otherwise, what happens if you change different "Customer
20" instances in different ways? When submit is called, which should win?

So yes: it still runs the SELECT, and gives you your *existing* object
if there is one, else it creates a new object.

Marc

 

[Marc Gravell]

Once it has the identity/primary key data, it compares that to the
internal list held by the context; this ensures that the context only
sees *one* instance of "Customer 20"; apart from memory, this also
ensures that you can only change-set for a single entity in the same
data-context. Otherwise, what happens if you change different "Customer
20" instances in different ways? When submit is called, which should win?

So yes: it still runs the SELECT, and gives you your *existing* object
if there is one, else it creates a new object.

Marc

 

[Marc Gravell]

Once it has the identity/primary key data, it compares that to the
internal list held by the context; this ensures that the context only
sees *one* instance of "Customer 20"; apart from memory, this also
ensures that you can only change-set for a single entity in the same
data-context. Otherwise, what happens if you change different "Customer
20" instances in different ways? When submit is called, which should win?

So yes: it still runs the SELECT, and gives you your *existing* object
if there is one, else it creates a new object.

Marc