architecture and distributed caching thoughts in combination with indeXus.Net SharedCache - Part 4

SharedCache thought no. 4: Granularity!

its a great keyword but we need to consider about it. Every application contains a natural granularity for all data. RDBMS* have a normalized granularity which are exposed over the table. Lets take ODBC / JDBC - based applications which provide normally an statement execution granularity and a result set granularity. ORM based applications and cache intensive applications often have an object oriented granularity that mirrors the data model from your RDBMS*.

The conclusion is the following: Normally each business object class provides a cache relation. Lets take the country and region, both will pick up data from the cache and not from the RDBMS after the first initial load. Each object intends to have a natural key. Lets say we can take the countryId or regionId or even make a combination with some other data like this: countryId + Iso2Code ;

Application Objects are ususally very complex with a lot other options, lets say that you enable your country class to contain a list with all its regions. If the regions already in the cache you dont need to access your RDBMS* system for nothing ;-)

Create yourself a caching strategy, this will make you life easier to manage large object graphs and enables efficient lazy loading functionality.

------------------

Download your copy of SharedCache: http://www.sharedcache.com

SharedCache will soon release session provider, which will assist you to work with SharedCache and ASP.Net Sessions.

Soon i will add some additional thought about how to provide optimistic transactional handling with SharedCache.

SharedCache is free and open source the only way you can see exactly what happens within your application.

* - RDBMS - relational database management system
** - DAO - Data Access Objects