My question is does the L2 cache work with linq statements ?
4 Answers, 1 is accepted
The L2 cache surely works with Linq queries the same way as with OQL. Can you please elaborate a bit on the scenario that you are using? Note that if you want to access objects from the L2 cache, the scope that was used to load these objects should be still alive.
Here is an example of a cached query:
the Telerik team
I have my cache strategy set to all and the L2 cache enabled.
I currently have a scope that is attached to the HttpContext of each request, this is used for updated.
I also have a static scope that is used for reading objects only (ii added this since you said it needs to still be alive).
My query selects from the static scope like this.
return from o in MyStaticExtent where
o.Role.AspnetUsers.Any(m=>m.UserName ==userName )==
I would expect the query to run once to the database and select all since my cache strategy is set to 'all', however it passes the where on to the database and calls the db for each subsequent request with a different parameter ...
How does the cache strategy work, and is it something im doing (the join maybe ?) that is preventing it from working as required...
So I created a test environment using LINQ and OQL Queries returning the same results.
- Usage of L2 caching is independent from the query language.
- L2 caching depends on the query result
The following example shows a query with LINQ.
I executed this query twice with condition 1, twice with condition 2.
The first condition delivers only a small number of records => L2 caching working on second execution
The second condition delivers more records, about 1000 => Records are read from the database while 2nd execution
_list = (From p in _scope.Extent(Of Bewohner)() Where p.BewField.Equals("Condition") Select p).ToList
In backend configuration 2nd level cache = true, cache query results = true, maximum objects in cache = 1000000, maximum queries in cache = 1000
In fact there might be a problem. By default the data is read on chunks of fifty objects so it is necessary to iterate the whole result set in order to load all the chunks in the cache. However if this is already done no additional calls to the database should be performed. It seems queries with more than 50 objects in the result are not cached correctly and we will have to investigate a bit further. We will notify you when we have more details.
the Telerik team