Does LLBLGen make use of some internal data caching mechanism to make DB data access more efficient? If so, how and where is data context (something that holds the cache) created? Where should I create and maintain this context for web applications and services?

Thank You, Vish

I dont beleive LLBLGen has any OOB caching functionality. Please correct me if I am wrong.

SQL Server has built in caching for data it reads, but its 100% managed by SQL Server. So thats not an option.

Microsoft Enterprise Library has a caching framework. You could use the ASP.NET Session State Service or the SQL Server Session State Service. All of these will provide issues when you need to load balance / cluster, because now you have a session affinity issue.

There are also commercial 3rd party applications available - ScaleOut Software -> http://www.scaleoutsoftware.com/index.html?gclid=CKnp6OPssJkCFRIcawodjVvs5g - NCache -> http://www.alachisoft.com/ncache/

So the real question is how much budget do you have, how much scale do you need right not, how fast do you need to scale, etc. All of these will dictate your caching solution.

So, LLBLGen doesn't cache any data at all? Even if I decide to use the Velocity cache from Microsoft or even just the ASP.NET cache...LLBLGen cannot take advantage of it? Can this be confirmed one way or the other?

Thank You, Vish

cgerecke wrote:

So, LLBLGen doesn't cache any data at all? Even if I decide to use the Velocity cache from Microsoft or even just the ASP.NET cache...LLBLGen cannot take advantage of it? Can this be confirmed one way or the other?

Thank You, Vish

We don't cache data. This might sound odd, at first, but please read my article about caching inside o/r mappers

The point is that if you query for data, a cache like velocity or ncache, the o/r mapper has to decide if, say, 10% of the entities are in the cache or not, but that's not doable without querying first, mitigating the reason why you want to cache in the first place.

The solution thus is: cache the data yourself if you want to, or better: cache the processed results (like in a webapp, cache parts of pages which are rendered after the data has been processed .This is more efficient than reading data from a cache).

Hi,

I agree that cache in the ORM is not going to be perfect or needs to be used carefully. But doesn't it make a lot of sense to cache data for large look-ups tables (list of cities for example)? In those cases, it would be nice to have some help from the ORM and have it handle it automatically instead of relying on the developers to check the cache for it every time?

Thank You, Vish

Sure, but you can do that yourself: fetch the lookup data, store it in the cache. the thing is: if you leave it to the o/r mapper, it can't know that the data read is all the data, unless it's told that it is all the data, however IMHO that's more effort from your part than it is when storing the lookup data in the cache. But let's not forget: it's even better to cache higher up the call chain.