This post is going to introduce you to the basic concepts of caching in WebCenter Sites as well as some

slightly more advanced caching concepts.

TL;DR With careful tuning of your WebCenter Sites caching strategy, you can dramatically increase the
performance of your system.
Of all the tasks you can undertake while designing a WCS implementation, caching is by far the most
important. It can mean the difference between a site thats lightning fast, and one that crawls, or cant
handle your user or editorial traffic.
Caching come in a few different flavours and applies to different application layers. These are the
following:
Resultset Cache
Content Server maintains a cache called the Resultset Cache which sits between the database and the
CatalogManager servlet which governs database access.
Content Server caches the resultsets in memory. The first time a query is executed, the results of that
query are stored in memory. When the same query is ran, the results are served from memory rather than
querying the database again.
The Resultset Cache Settings are specified in the futuretense.ini configuration file and include:
default number of resultsets to keep in memory
default amount of time to keep resultsets in memory
how to calculate the expiration time
table-specific settings
When the maximum is reached, the least recently used resultset is flushed. When a table is updated, all
corresponding resultsets are flushed.
Using the Support Tools, it is possible to inspect a graphic representation of the contents of the Resultset
cache, including which resultsets are full, and the percentage of queries that are hitting (or missing) the
cache.
The idea is to maximise the number of queries that hit the cache, and to size the caches big enough that
the maximum is rarely reached.
Satellite Server Cache
All initial requests to a Content Server installation should (ideally) hit the Satellite servlet first. If they
dont, youre probably doing something wrong. Satellite Server has no database and most of the contents
of its cache will generally be held in memory, although this is configurable.
In general, Satellite Server spends most of its time assembling pagelets and proxying requests to the
ContentServer and BlobServer servlets. Pagelets are smallish parts of a page which are subsequently
turned by Satellite Server into an entire webpage.
There is an an ideal number of pagelets which compose a page.
If there are too few, it can result in large swathes of the cache being invalidated during a publish.
If there are too many, Satellite Server can end up spending large amounts of time putting together all the
tiny fragments. Generally youll want no more than a couple of dozen pagelets in any given page.
Content Server Cache
Next up is the core Content Server cache. This executes the code from your CSElements and Templates
and from this generates and stores pagelets at the request of Satellite Server.
Note that Satellite Server itself cannot generate the pagelets, it only assembles them. Note also that the
caching parameters can be set separately on Content Server and Satellite Server.
Content Server can also assemble pages without the assistance of Satellite Server, but this is not
recommended. It is more expensive than using the extra layer of caching that Satellite Server provides.
InCache
Historically, the Content Server cache utilised the database and filesystem to store its cache fragments.
These fragments were stored in a table called SystemPageCache, and on the filesystem in the location
[shared_foler]/SystemPageCache.
The issue with this was that that table could get big very quickly, and there are also three files stored on
the filesystem for every entry in the table (the .qry, .hdr, and .txt files).
The files are stored in nested, numbered directories, and can easily run into millions of files. To work
around the limitations with this system, InCache was developed.
This system is built on top of Ehcache, a product from Terracotta. Compared to the legacy method of
caching to the database, inCache offers improved website performance. This is because the cache is
moved from the filesystem and database into memory.
Naturally, this move can drastically increase the usage of the JVM heap, so careful sizing of the heap is
necessary when migrating from the old caching method to InCache.
It is also decentralised as opposed to the older solution, so each Content Server instance in a cluster
maintains its own cache, and invalidation messages are sent to each cluster node when a cache entry is
invalidated.
Asset Cache
This is a relative newcomer in the caching architecture, only becoming available with the 7.6 release of
the product, because it is based on the InCache framework mentioned above.
Rather than caching pagelets, it caches the results of loading an asset, for instance with the asset :load tag,
the AssetDataManager.read Java method, or the REST API.
It protects WebCenter Sites performance by taking up load that would otherwise affect the database.
In Summary
What all of these caches are working towards is to reduce the load on the various components of your
system, particularly the database.
If you think of the application stack as a funnel, a good caching strategy will ensure that the vast majority
of the requests are dealt with at the upper levels of the stack.
The Satellite Server cache should field most of the traffic, a few requests may be dealt with by the
Content Server cache and Asset Cache, a small number might get as far as the resultset cache, and very
few would be reaching all the way to the database.
Flush the cache with a URL like this:
http://DOMAIN/servlet/CacheServer?all=true&username=USERNAME&password=PASSWORD
If it worked, you should see a response like this: CacheServer flushing all pages.
Trouble shooting tips.
If flushing gives you this error: CacheServer : No access allowed for requested action.(Force page
flush), check the following.
o Are you sure your username and password are correct?
o Does that user name have SiteGod ACL?
o Are you logged in?
I made some changes and can't see them on refresh! Check your URL. If it is a satellite URL
(http://DOMAIN/servlet/Satellite), change Satellite to ContentServer, i.e.
http://DOMAIN/servlet/ContentServer and refresh again.
CSElements called by SiteEntry - to cache or not to cache.
o If it is static (like some non changing content or maybe a Javascript file), cache it. In the
SiteEntry, set "Pagelet Cache Criteria" to "true,*".
o If the element is dynamic, i.e. it performs some processing and the output should be
different each time, don't cache it. In the SiteEntry, set "Pagelet Cache Criteria" to
"false".
o See CacheInfo String Syntax section of the developer pdf for a detailed description of
how to use this setting.
o I said don't cache, but it is! I found (CS 5.5) that when I set my SiteEntry initially to
"true,*" and changed it afterwards to "false", it was still being cached. To fix it, I deleted
and re-created the SiteEntry.
Explicitly Removing Entries from Cache
Individual entries can be removed from the Satellite Server cache either manually or using
CacheManager, as explained in this section.
Manual Removal
Satellite Server includes a servlet called FlushServer. By submitting a GET request to this servlet
(specifying the username, password and reset parameters), it is possible to flush all of the contents of the
Satellite Server cache. It is not possible to flush individual entries using GET.
Automatic Removal
As described above, it is possible to flush the Satellite Server cache using CacheManager. As described,
CacheManager is only able to flush entries on Satellite Server if a corresponding object is cached on
Content Server. This is the case because of the way Content Server tracks the contents of the Satellite
Server cache.
As described above, it is possible to flush the Satellite Server cache by using CacheManager, as long as a
corresponding object is cached on Content Server. The corresponding object is required because of the
way Content Server tracks the contents of the Satellite Server cache.
Following are some of the important properties related to PAGE CACHING in FUTURETENSE.INI
file.
1. cs.nocache
2. cs.pgCacheTimeout
3. cc.SystemPageCacheCSz
4. cc.SystemPageCacheTimeout
5. cs.alwaysusedisk
6. cs.freezeCache
7. cs.manage.expired.blob.inventory
We will now have a detailed look about these properties.
cs.nocache
This forcibly disables the adding and serving of pages from cache. Legal values are true and false.
cs.pgCacheTimeout
This is the default lifetime of a cached page, specified in minutes. Specify 0 (zero) to never time pages
out from the cache.
Sites that use intelligent page cache invalidation through CacheManager, including CS Direct sites
written using CS Direct 4.0 coding practices and later, will be able to rely on automatic cache invalidation
so timeout is not relevant.
Only advanced users should modify the value of this property. Setting it to a value greater than zero
when Satellite Server is used can result in pages that cannot be ever be explicitly removed from the
Satellite Server cache.
cc.SystemPageCacheCSz
This is the maximum number of pages that will be cached in memory. Pages will still be cached to the
database but for better performance pages should be cached to memory too. This property allows you to
specify how many pages will live in memory. Default value is 10,000, reduce if memory is at a
premium. Performance may suffer.
cc.SystemPageCacheTimeout
This is the default lifetime of a cached page in memory. Cached pages will live in the database until they
are set to expire but for performance reasons pages are also cached in memory. This specifies the timeout
(minutes) of the memory cache. If memory is at a premium you may shrink this value but it is set to 24
hours (1440 minutes) by default.
cs.alwaysusedisk
This specifies the default behavior for page entries in the site catalog that have no specific cache override
property. If set to yes, then pages served from the Content Server will be cached unless explicitly
specified otherwise in cacheinfo. Though the name indicates that pages are cached to disk, they are in fact
cached to the database using url-columns.
Legal values are yes and no.
cs.freezeCache
This controls whether Content Server expires cached pages on a schedule. Specify yes to prevent the
creation of an event to periodically clear the page cache. No pages whose expiry date has passed will
ever be served regardless of this property value because their expiration is checked immediately prior to
serving.
Legal values are yes and no.
cs.manage.expired.blob.inventory
This property specifies whether or not blob dependencies will be flushed from the inventory
(SystemItemCache table) when the blob times out from cache.
If set to true, then blob inventory items will not be cleared from the inventory table. This improves the
reliability of CacheManager such that blobs can be flushed from SatelliteServer when the blobs have
expired from ContentServer. The cost is increased use of space in the database. If set to false, then when
a blob expires from the cache, the corresponding inventory entries will also be removed from the
database. If the cache is being actively managed, the blobs should not ever expire from the cache.
The default value is false.
The term PAGE constitutes a very important concept in FATWIRE.
There are a few terminologies in Fatwire related to Page, such as PAGE, PAGELET , PAGE NAME,
PAGE ASSET.
Really they are confusing. At least, Im very much confused with these terminologies in the beginning.
We will discuss the basic differences between these terminologies, so that we will get some clear cut idea,
and we will know when to use which term.
1. PAGELET: A Pagelet is the result of an HTTP request. It is a piece of a rendered page. Its one among
several pagelets that are rendered and displayed in a browser window. It has an associated element file,
and that element has logic to generate this Pagelet. A pagelet can be cached in the Content Server and
Satellite Server page caches.
2. PAGE: A Page is nothing but the result of an HTTP request. It is the one which is displayed in a
browser window. Sometimes, a page is created by compiling several pagelets into one final, displayed or
rendered page. It has an associated element file, and that element has logic to generate this page. A page
can be cached in the Content Server and Satellite Server page caches.
3. PAGE NAME: This is the complete name given to the page. For example, if Full is the name of a
page, and if its type is Article , and if it is in the site Sample, the following will be the PAGE NAME :
Sample/Article/Full.
4. PAGE ASSET: A page asset is the one which simply act as containers for the actual content. These
containers are arranged in the SITEPLAN tab of the TREE to facilitate the ease of navigation.You
associate other content and other assets with these PAGE ASSETS and then you publish them.
Caching in Fatwire
Fatwire supports double-buffered caching.WebCenter Sites double-buffered page caching method uses
the WebCenter Sites and Satellite Server caches in tandem on live web sites. Double buffering ensures
that pages are always kept in cache, either on WebCenter Sites or Satellite Server, to protect WebCenter
Sites from an overload of page requests and prevent the live web site from displaying blank pages and
broken links.
By default, WebCenter Sites and Satellite Server use inCache as their page caching framework.
Satellite Server
Satellite Server is a caching application. It supplements WebCenter Sites caching functionality by
providing additional page caches.
By default, co-resident Satellite Server is installed on the same machine where WebCenter Sites is
installed. We can further improve our systems performance by installing Satellite Server remotely so it
can cache pages and pagelets closer to their intended audience. Remote Satellite Server hosts are fast,
inexpensive caches of WebCenter Sites pages. They reduce the load on the WebCenter Sites host,
dramatically increase the speed of page delivery to your site visitors, and provide a simple and
inexpensive way to scale our WebCenter Sites system.
When the load balancer routes an HTTP request for a page to Satellite Server, Satellite Server either
serves the page if the page is in its cache, or if the page is not cached, it
forwards the HTTP request to WebCenter Sites.
The basic chain of events is the following:
1. Satellite Server checks its cache.
2. What happens next depends on whether the page is in the Satellite Server cache:
Page is in Satellite Server Cache:
1. Satellite Server serves the page to the visitors browser.
2. In this case, Satellite Server does not have to forward the request to the WebCenter Sites
database, thus reducing the load on the WebCenter Sites database.
Page is Not in Satellite Server Cache
1. Satellite Server forwards the request to WebCenter Sites.
2. If WebCenter Sites has the page in its cache, it returns the cached page to Satellite Server. If the
page is not in the WebCenter Sites cache, WebCenter Sites
renders the page, caches a copy, and sends the page to Satellite Server.
3. Satellite Server then caches the page and serves it to the visitors browser. When requested again,
the page will be served from the Satellite Server cache, which
reduces the load on the WebCenter Sites database.
Each Satellite Server application is independent of every other Satellite Server application. An individual
Satellite Server application has the following characteristics:
It maintains its own cache.
It cannot request pages or pagelets from another Satellite Server application. It can request pages or
pagelets from only the WebCenter Sites core.
Satellite Server Servlets:
Satellite Server is made up of several servlets: one that caches and serves pages, and two that manage the
cache:
Satellite Caches pages at the pagelet level. The Satellite XML or JSP tags in our elements indicate
which pagelets should be cached, and they control various SatelliteServer settings.
Inventory Enables us to examine the Satellite Server cache so we can obtain the information we need
to manually flush individual pages or pagelets from the cache when necessary.
FlushServer Handles all types of cache-flushing. FlushServer can either flush the entire cache, or can
flush individual items from the cache.
In Short Satellite server
Caches pagelets instead of pages
Its better for pages that change frequently
What is InCache?
Oracle WebCenter Sites and Satellite Server ship with a caching system called the inCache framework, or
simply inCache. This system is built on top of Ehcache, an open
source, standards-based product from Terracotta. Compared to the legacy method of caching to the
database, inCache offers improved website performance.
inCache is a high performance, memory-based page and asset caching system that eliminates the need to
cache Oracle WebCenter Sites data in a central, shared repository
and shared file system.inCache also supports asset caching, by default.
The inCache framework offers the following benefits:
High performance.
Decentralized architecture. The inCache framework eliminates database caching and shared
disks.
On-demand page evaluation and invalidation. Nodes validate and update their currently cached
content only when the content is requested.
Failover and persistence. Nodes that are shut down retain data in their local caches and update
themselves upon restart against a centrally managed record of invalidations.
What is Page Caching?
Page caching is implemented at the template level and is used to cache pages on the WebCenter Sites
system. Page caching plays a significant role in system performance. If
an element is not changed and it will generate the same page each time it is invoked, why make
WebCenter Sites process the element each time it is called? If the generated page is cached, it can be
served much faster than it can if it must first be generated.
WebCenter Sites alone (independently of Satellite Server) can separately cache each page or pagelet that
is identified by a page entry in the SiteCatalog table. We can mark the expiration date of any pagelet in
the cache by specifying a value for that page entry in that table.
Page caching is made especially effective by the addition of Satellite Server.
Resultset Caching
Resultset caching is another feature that can greatly enhance system performance. When the WebCenter
Sites database is queried by any mechanism, the WebCenter Sites
application can cache the resultset that it returns. The WebCenter Sites application keeps track of every
table in the database; whenever a table is modified, it flushes all the
resultsets that were cached for that table.
Whenever the database is queried, WebCenter Sites serves a resultseteither a cached resultset or an
uncached resultset. Resultset caching reduces the load on your database and improves the response time
for queries.
Asset Caching
Asset caching is a memory-based system that is built on the inCache framework to optimize the
performance of WebCenter Sites by taking up load that would otherwise
affect the database. In WebCenter Sites, programmatic usage of assets consists of loading and rendering
their attributes. Given that assets are loaded by templates, which are stored in the WebCenter Sites
database, AssetCache is used only on WebCenter Sites nodes. Asset caching includes the AssetCache
container component which functions by caching assets and interacting with existing inCache
components.
Understanding Fatwire Multiple Caches
When it comes discussing the Fatwire cache, I notices very often some confusion in customer minds. I
am not very surprised of this, since Fatwire has multiple caches and their relation is pretty complex.
In this post I will try to clarify the situation, giving an overview that explains (almost) all of the them. I
am omitting here the BlobServer cache for clarity.
The structure of the available caches is depicted in the diagram below. Read on for an explanation.


Satellite Pagelet Cache
When you visit a Fatwire website, you normally access to one of the Satellite Servers.
In the diagram there is only one Satellite, but in a normal deployment you should have many satellite
servers, ideally geographically distributed in net, and the possibly located close to your browsing location,
internet-wise.
Satellite Servers are the ultimate cache in place. They cache the site, splitting web pages in pagelets. A
pagelet is a piece of already rendered html. It is important to understand that a pagelet is not a whole
webpage, but actually only a part of a page (think to the header, a summary, a generic block).
Pagelets are assembled in place by Satellite to build complete web pages. Note that because pagelets are
expected to be small enough to be kept in memory, assembling of a page is expected to be very fast (no
database is involved, mostly of the cache is kept in-memory except bigger files are stored on the disk).
Actually Satellite spools to disk pagelets larger than a given threshold (configurable in property files).
However Satellite does not have the ability to render templates, so when a pagelet expires or is
invalidated, Satellite must grab the updated pagelet from Content Server.
Satellite cache can be inspected using a specific tool, the Inventory servlet (using the appropriate
username and password), and can be flushed using the FlushServer servlet.
Content Server Pagelet Cache
ContentServer generates pagelets on request of Satellite, executing template code (either JSP or XML). It
also caches the output of the rendering, for 2 reasons:
First reason, Satellite is optional, and Content Server can run a site without Satellite, and must do
it efficiently.
Second reason , multiple Satellites can be deployed, so you may need to serve the same pagelets
more than once. Also a Satellite can crash, or another satellite be added, so serving pagelets must
be fast as well.
ContentServer cache is the second cache in place. You can inspect the Content Server Cache looking at
the SystemPageCache database table and its attachments. The servlet to clean the content server cache is
CacheServer.
Please note that when you inspect the ContentServer cache you will see the pagelets generated for
satellite, however cached pagelet for Satellite are stored in memory within satellite. So empting
ContentServer cache won't clean also Satellite cache. If you want to clean also Satellite cache, that you
have to do it manually.
A complete reset of the front-end cache involves both all the Satellite Servers and Content Servers.
InCache Asset Cache
So far we have seen caches that store pagelets, that are fragments of rendered html. Those caches works
with templates having cache enabled.
However it is common to have some templates that cannot be cached. Typically this happens with
certain templates that always return a different rendering (for example, searches), and caching the output
pagelet can is difficult and fundamentally pointless.
The most recent addition to the family of Fatwire caches is InCache, that basically caches the underlying
"pojos" used for rendering. You may ask what those pojos are.
When you execute template code, you perform calls like <asset:load name="theAsset" ...> or
<assetset:setasset name="theAssetSet" ...> to load assets. Please note that "theAsset" or "theAssetSet"
are actually Java Objects (POJO = Plain Old Java Objects) that will be used to render the content.
Loading them is expensive because a lot of database requests may be required (or at least once, that is by
far the slower operation).
Enabling InCache, those pojos are cached as well. So this cache helps to speed up the rendering of
uncached templates. Indeed, the vast majority of the time is spent querying the database, and reusing
already queried POJO helps a lot in speeding up also uncached templates. It also helps saving memory
and reducing garbage collection.

ResultSet Cache
Last but not least, there is also the old and good cache of database queries. When you query a database,
you store the result in a list in memory (in Fatwire they are generally IList, that caches the output of Java
ResultSets). As long as no one accesses any more to the table from where the IList was generated,
running the same query will produce the same result, so it may be cached.
Result Set cache is caching results of database queries for each query executed. ResultSet are associated
to tables, so the cached results are valid until the underlying database table changes. The result set cache
is invalidated table by table whenever someone write in the database table from where content was
retrieved.
This cache is helpful because ultimately all the content must be extracted by the database, but is is useful
also when you write custom queries. It can be tuned editing futuretense.ini and flushed using
CatalogManager servlet.

CS cache, SS cache, Blob cache, RS cache:
Webcenter Sites offers double buffered caching means caching at two different places co-resident satellite
server(CS Cache) and remote satellite server (SS Cache). In reality whoever installs Fatwire will get the
co-resident SS by default and installs at least one remote satellite server. Remote SS helps in speed
delivery of the pages and reduces the load to content server (CS). Along with this the traditional result set
cache is also available to reduce the load on database. The queries to the db is cached and it serves the
request if the same table is not updated.
So, what are all the object that can be cached?
Blobs, entire page or a portion of the page. Portion of web page is called pagelet. Sites allows you to
control the pagelet that needs to be cached in satellite server and content server. All the cacheable objects
will be cached either in disk or memory depending on the size of the objects. Size can be set in satellite
properties file which will allow the objects to store in disk. Smaller objects are retained in memory.
When the content is dynamic and real time then there is no point in caching those pagelets for example,
search results page. Also never expiring blobs likes logo image need not be cached. Put them in web
server root folder and refer it in the page using simple html img src tag.
Page request handling:

Request comes to SS.
SS cache serves the page/pagelet if available else request passed to CS cache
CS cache serves the page/pagelet if available else checks in resultset cache.
RS cache serves the resultset if available else db is queried and the resultset is cached,
page/pagelet is cached in CS cache and then SS cache
inCache: (from 7.6)
inCache is based on opensource java caching framework that was introduced in Fatwire 7.6. It is optional.
We can disable and continue with traditional caching mechanism. inCache works very well in clustered
environment where multiple nodes to update their cache independently. You can enable inCache for page
and asset individually.
inCache consists of four different caches pageByQry (simply PageCache), AssetCache,
dependencyRepository and notifier. Last two is common for page caching and asset caching.
A. Page cache is loaded with
page details
B. Asset cache is loaded with asset details
C. Dependency cache logs the dependency of the page/asset
D. Notifier receives the page/asset invalidation and communicates to the cluster nodes.
Cache will be flushed when:
asset is updated / published
assets expiration time (based on the property files) reaches
using FlushServer servlet (Inventory servlet is used to inspect the cache)
Caching is always a broad topic in any design. Every CMS/Framework provides its own ways to
implement cache. I am using Fatwire 7 CMS. Fatwire provide 2 level of caching:
1. Content Server Cache (CSCache)
2. Satellite Server Cache (SSCache)
Note: I will use CS and SS for Content Server and Satellite Server.
Lets have a look how fatwire serve a request:

Every time a user (End user) hit a page (A), the request goes to SS
SS check if the requested page/pagelete is available in its cache. If the requested page/pagelate is
available in SS cache, then it servers the requested page back to end user (E,F) otherwise SS
request CS to provide it the requested page/pagelete (C)
CS check if the requested page/pagelete is available in its cache. If the requested page/pagelate is
available in CS cache, then it servers the requested page back to SS (D) otherwise CS follow the
following steps:
o CS process the code (Templates/CSElements) to generate the requested page/pagelete.
o Cache* the page/pagelete on CS
o Return the output to SS (D)
Now, SS cache* the processed page/pagelete and return the complete page back to requested user
(E,F)
* Its not necessary that we cache every page/pagelete. If a page is cached but its internally calling
number of uncached Elements (CSElements/Templates) then the cached page save the call for that
element instead of html output. So every time a user request for a page, these uncached elements will got
evaluated on CS.
Understanding cache dependencies
WC Sites (formerly Fatwire ContentServer) is a content oriented CMS, as opposed to other page oriented
CMS. The exact meaning of being driven by the content is that you are required only to describe your
content without considering how this content will be actually rendered .
This idea has a few consequencies that must be taken in appropriate consideration when you design and
code a WCS implementation.
The biggest problem in this separation is that you must keep some track of the relation beetween your
content and its rendering.
(Well this is not actually totally true, considering insite editing, that is a presentation oriented technology,
however it does not change the concept - content and presentation are separated but related).
The relation between presentation and content
To better explain the problem consider a generic content, let's say an article in your site.
On the CMS you want to add it usually just once, but on the site the same article can appear a number of
times in different web pages, in different formats.
For example an article can be displayed as a full text in a web page, as a summary in another web page or
just as a simple link in many others.
All those occurrencies appears in different web pages, and you have to update all of them when the
underlying content model changes. For this reason WCS stores in the database dependency
informations.
The main reason to keep those informations is because they are needed for an easy and efficient updating
of the cache when the content changes. In fact, when the site is rendered, blocks of html (conventionally
called pagelet) are generated from the content model and usually cached.
For each of those pagelet a dependency is generated and stored.
When the content model is changed all the stored dependencies are walked through and the dependent
pagelets are invalidated and regenerated.
In practice
You can see all of this in action simply inspecting the table SystemItemCache. This table is somewhat
obscure but it keeps one of the more important informations used in publishing: dependencies between
assets and pagelets.
This table is calculated while rendering the content model in an actual live site. Many dependencies are
actually calculated by the render:calltemplate. When you call a template, you are also declaring that a
new pagelet (the one that will be rendered by the template you are invoking) will depend on the asset
specified by c and cid. So a new dependency will be recorded for this asset.
Dependencies can also be recorded explicitly using the render:logdep tag. Indeed, you may notice that
when you create a new template, some code involving a logdep is automatically added.
That code should NOT be removed: it is adding a dependency between the template itself (the code
generating the pagelet) and the generated pagelet. Obviously, when you change the code generating the
pagelet, that pagelet must be regenerated.
In general, a pagelet rendering a given asset (identified by c and cid) depends always on the asset itself
(so a c:cid dependency is required) and the template that render it (so a Template:tid dependency is also
required).
However things can became much more complex than this. There are other sources of dependencies: for
example searchstate calls usually generate some dependencies, and an index gathered by a search can
depend on so many assets that... an "unknown dep" can be generated.
Those special dependencies basically invalidate each pagelet when any asset of a given type changes.
Common Errors
Unfortunately, caching and even worse dependency management are often misunderstood.
Some (untrained) developers are somewhat vaguely aware of the caching, but very often they completely
ignore dependencies.
A common error is to create a template that depends on two or more assets (the first one being the c/cid,
while the other is specified with extra parameters). Unfortunately, only the dependency specified by c/cid
is actually recorded, so when the other asset change, the corresponding pagelet is NOT invalidated.
The net effect is a website that won't be updated when the content change (unless you invalidate all the
cache).