Caching Consistency vs. Static Object with nHibernate/ASP.NET

I am a complete newbie to both caching, nhibernate, and everything involving the two, so this question may be excessively stupid.

I have certain instances of objects that are used by multiple other objects in my system. So for instance..

class Template {
  // lots of data
}

class One {
  IList<Template> Templates { get; set; }
}
class Two {
  IList<Template> Templates { get; set; }
}
class Three {
  IList<Template> Templates { get; set; }
}

Now, then, certain instances of Template are going to be used very, very frequently. (think like, every 20 seconds) and it includes a lot of things that need to be mathematically computed.

My question is basically which approach will yield the least stress on my database/server.

Am I best to just leave everything to Level 2 Caching in nHibernate? Or am I wiser to retrieve the Template object and store it in a static variable when my ASP.NET app开发者_开发问答lication starts up, and refresh this variable if it changes?

I've looked at some of the other similar questions around SO but I am still very much in the dark. Most of the documentation on caching assumes a good deal of knowledge on the subject, so I'm having a difficult time discerning what the optimal process is.

once every 20 second doesn't really sound very stressful. You need to weight the need for updated data vs the stress you can live with on your database.

2nd level cache won't necessarily help you in this case, since you use collections of objects. In order to know which object it needs, it still need to query the database, and if you do that it might even fetch the data anyway (unless it's a lot of raw data in the entities).

You basically have three different options:

1st level cache For each connection/session that you make, NHibernate will always cache the unique entity that it has fetched. Every time you try to get a single entitity based in it's identifier (primary key), it will first check it's first level cache. This does not apply to collections of entities though, unless you can force NHibernate to only get "identifiers" for the collection and the get them one by one (usually very slow)

2nd level cache This cache will available for each and every connection/session, and try to fetch the data from cache before it hits the database. Same rules apply as for the 1st level cache, that you can't get collections to an entity without querying the database unless it has already been loaded.

custom cache You can always take care of caching your self, however, that way you need to model your classes accordingly (having Template objects stored, and the collections only keep track of the identifier instead of Template objects). If you refactor like this, 2nd and 1st level cache would still be equally useful though.

I will give you an example that shows you what I'm talking about:

if One contains templates with identifier [1,2,3,4] Two contains templates with identifier [2,3] Three contains templates with identifier [3,4,5]

In order for NHibernate to know that One needs templates 1,2,3,4, it needs to query the database. 1,2,3,4 will be cached individually here. In order to actually know that Two needs entity 2 and 3, it still needs to query the database. It can't possibly know that 2,3 is also part of the collection in Two. Si it won't fetch them from cache, because it will select Template objects that belongs to class Two, hence full data. That is why caching won't help you here.

I think you need to give more details on what kind of data it is that you will be processing, and how it will be stored and updated in order to get an answer that is useful.

Static variables would be the less stress on your server, however that imposes some restrictions, specifically, it would be much harder to scale (web garden/farm), if you don't need to scale, that's the option you're looking for