Visual Studio and .NET Framework Home
LINQ-to-SQL doesn't use cache for lookup
4/24/2008 11:53:37 PM
User(s) can reproduce this bug
LINQ-to-SQL caches returned objects; this serves to provide object identity (same instance returned each time), but it is also claimed that this is used to resolve some lookups:
Quote 1: http://msdn2.microsoft.com/en-us/library/bb399376.aspx
If the object requested by the query is easily identifiable as one already
retrieved, no query is executed.
Quote 2: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=345635&SiteID=1
The cache is checked when the query is a simple table.Where(pred) or table.First(pred) where the predicate refers only to the primary key.
However, I can find no use-case where it actually behaves this way. I can brute-force into the cache using reflection, but this is not ideal. Full sample code available.
.NET Framework 3.5
Windows XP Professional
Operating System Language
Steps to Reproduce
Example code attached; this is a console exe (against Northwind) that fetches an employee, then performs 4 simple lookups just using the primary key; each results in a round trip.
5 round-trips are performed
1 round-trip is performed; others should be fetched from cache since lookup is only by primary key
TAP Code (if applicable)
You can indicate your satisfaction with how Microsoft handled this issue by completing this quick
3 question survey
to post a comment.
Please enter a comment.
on 8/18/2008 at 7:45 AM
Validated for Single(x=>x.ID == id), but Where(x=>x.ID == id).Single() still results in round-trip. For info.
on 5/15/2008 at 12:08 AM
Marked as resolved, but no indication how? Not fixed in SP1 beta, for example...?
on 4/27/2008 at 9:23 PM
Thanks for your feedback.
We are escalating this issue to the appropriate group within the Visual Studio Product Team for triage and resolution.
These specialized experts will follow-up with your issue.
Visual Studio Product Team
to post a workaround.
Please enter a workaround.
© 2014 Microsoft