Basirudin Rachman

See also: Other Geeks@INDC

Caching Strategy for Collection Object – Part I

Background

In a cache management pattern, usually the object that stored in the cache will exactly same with the object returned from the real data store.

Following diagram shows the working of cache:

CacheRepositoryAgentDiagram

As shown in diagram above, the cache repository agent (CRA) will responsible to return object requested by the client.

1. Client request Object.

2. CRA will check to the cache, if the object available, than return it back to client.

3. If not exist in the cache, get the object from repository (REP) (i.e. database repository), return to the client and asynchronously add it to the cache.

Problem

With the following condition, some problems might be appeared when the usage of CRA and Cache is come after the system running well in the model of Client <-> REP. The problems are:

1. Object returned by REP is not the one that expected by CRA to be stored in the Cache.

2. More precisely, if the CRA expects object which contains a raw data structure, but the REP return an object which contains processed data structure.

Solving the problems above is actually the objective of this article. We will assume the object used by REP and CRA is not a simple object such like a Person object which can be retrieved using a key/ID (REP.GetByID(id) or CRA.GetByID(id)), but the object that contains collection of item, that act like a table in database but stored in the Cache (we call it CollectionObjectInfo). Following diagram shows the sample structure of CollectionObjectInfo:

CollectionObjectInfo

While the object that returned by REP is already in product format, i.e.: an xml string produced from the combining subset data of the DataList:

   1: <?xml version="1.0" encoding="utf-8"?>
   2: <ObjectInfo>
   3:   <data>v11, v12, v1n</data>
   4:   <data>vm1, vm2, vmn</data>
   5: </ObjectInfo>
Share this post: | | | |
Posted: Jul 23 2009, 08:45 PM by basir | with 2 comment(s)
Filed under: , ,

Comments

dondy said:

Cache update strategy-nya gimana Sir ?

# July 23, 2009 11:45 PM

basir said:

@dondy:

Sebenernya untuk proses update out of context topik ini. Tapi sediit info untuk proses update: at least ada 2 kejadian yang membuat cache terupdate untuk obyek koleksi: delete dan update.

Delete sendiri, dalam kasus ini meiliki 4 tujuan: delete beberapa row, delete satu column, update row, delete object keseluruhan. Sementara proses update: update row, update column.

Seharusnya kedua proses ini membuat objet yang di cache menjadi invalid alias paling gampang di remove aja. Hal berbeda untuk obyek koleksi yang invalid bisa jadi rownya saja, dan invalid row ini yang disimpan di dalam informasi invalidated rows - (kasus update beberpa row pada proses delete dan update obyek).

Next time client panggil cache agent, maka si agen akan konstruk data lagi berdasarkan informasi invalidated rows ini (Selama dalam range data yang di query ada invalidated rows).

# July 24, 2009 5:41 AM