Few months ago I was working for a troubleshooting investigation regarding an ACL not expected behavior. My client was on iSeries with WCS 7 and B2B stores. I found the issue was deriving because of a base cache default configuration set by InitializationServlet.

The following brief article describe the issue and the solution adopted.

The WebSphere Dynacache- the main tool WebSphere integrates for caching strategies- can be imagined like an HashTable stored in the JVM Heap, with disk offload options and rules defined for retrieve and invalidate objects. In addition, Dynacache is supported in a cluster environment using the Distribute Replication Service- DRS.

The invalidation is a powerful feature of Dynacache but sometimes- like in the case I'm reporting- it has its logic split between XML configuration and JSP coding.

In particular, I refer to the fragments invalidation. Let's take the following example:

• JSP Page (root): page1.jsp
• Fragment 1 (1st level child): fragment1.jspf
• Fragment 2 (2nd level child): fragment2.jspf

In terms of code, page1.jsp will have something like:

...

<% out.flush() %>
<c:import file="${filedir}page1.jsp"/>
<% out.flush() %>

...

and so do fragment1.jspf. 

In addition, cachespec.xml will have the following configuration:

<class>servlet</class>
		<name>/directory/page1.jsp</name>
		<property name="do-not-consume">true</property>
		<property name="save-attributes">false</property>
		<property name="consume-subfragments">true</property>
...

The problem: despite the configuration is the IBM's InfoCenter suggested one, the fragments do not seem to be invalidated properly. In other words, when something changes in the fragments page1.jsp does not change at all.