Author: mircea.markus Date: 2007-10-31 06:09:37 -0400 (Wed, 31 Oct 2007) New Revision: 4712 Modified: core/trunk/src/main/docbook/userguide/en/modules/eviction_policies.xml Log: added 'structural' nodes as an use case for resident nodes Modified: core/trunk/src/main/docbook/userguide/en/modules/eviction_policies.xml =================================================================== --- core/trunk/src/main/docbook/userguide/en/modules/eviction_policies.xml 2007-10-30 23:32:00 UTC (rev 4711) +++ core/trunk/src/main/docbook/userguide/en/modules/eviction_policies.xml 2007-10-31 10:09:37 UTC (rev 4712) @@ -146,7 +146,26 @@ <literal>Node.setResident</literal> should be used. By default, the newly added nodes are not resident. The <literal>resident</literal> attribute of a node is neither replicated nor transactionable. </para> + <para> + A good use case for this would be marking the internally build nodes as resident. E.g. + <programlisting> + <![CDATA[ + ... + cache.put("/a/b/c", "k", "v"); + cache.getRoot().getChild("/a").setResident(true); + cache.getRoot().getChild("/a/b").setResident(true); + ... + ]]> + </programlisting> + In this example, the nodes <emphasis>/a</emphasis> and <emphasis>/a/b</emphasis> are internally build for + supporting the existence of node <emphasis>/a/b/c</emphasis>. If so, they are good candidates for being + marked as resident nodes: this would lead into performance improvements as no eviction events would be + generated when accessing <emphasis>/a</emphasis> and <emphasis>/a/b</emphasis>. N.B. when adding attributes + to such a node, e.g. <emphasis>cache.put("/a", "k", "v")</emphasis> it would make sense to mark the nodes + as non resident again and let them be considered for eviction. + </para> + </section> <section>