[jbosscache-commits] JBoss Cache SVN: r5403 - in core/trunk/src/main/docbook: tutorial/en and 1 other directories.
jbosscache-commits at lists.jboss.org
jbosscache-commits at lists.jboss.org
Sat Mar 8 06:34:55 EST 2008
Author: manik.surtani at jboss.com
Date: 2008-03-08 06:34:54 -0500 (Sat, 08 Mar 2008)
New Revision: 5403
Modified:
core/trunk/src/main/docbook/faq/en/master.xml
core/trunk/src/main/docbook/tutorial/en/master.xml
core/trunk/src/main/docbook/userguide/en/modules/basic_api.xml
core/trunk/src/main/docbook/userguide/en/modules/cache_loaders.xml
core/trunk/src/main/docbook/userguide/en/modules/configuration.xml
core/trunk/src/main/docbook/userguide/en/modules/configuration_reference.xml
core/trunk/src/main/docbook/userguide/en/modules/deployment.xml
core/trunk/src/main/docbook/userguide/en/modules/eviction_policies.xml
core/trunk/src/main/docbook/userguide/en/modules/replication.xml
core/trunk/src/main/docbook/userguide/en/modules/transactions.xml
Log:
Added roles to program listings to enable syntax highlighting
Modified: core/trunk/src/main/docbook/faq/en/master.xml
===================================================================
--- core/trunk/src/main/docbook/faq/en/master.xml 2008-03-07 17:39:36 UTC (rev 5402)
+++ core/trunk/src/main/docbook/faq/en/master.xml 2008-03-08 11:34:54 UTC (rev 5403)
@@ -345,7 +345,7 @@
JBoss MBean. Here is a code snippet:
</para>
- <programlisting><![CDATA[
+ <programlisting role="JAVA"><![CDATA[
import org.jboss.mx.util.MBeanServerLocator;
import org.jboss.mx.util.MBeanProxyExt;
@@ -1065,7 +1065,7 @@
issue:
</para>
- <programlisting>
+ <programlisting role="JAVA">
import org.jboss.invocation.MarshalledValue;
public class CacheService
Modified: core/trunk/src/main/docbook/tutorial/en/master.xml
===================================================================
--- core/trunk/src/main/docbook/tutorial/en/master.xml 2008-03-07 17:39:36 UTC (rev 5402)
+++ core/trunk/src/main/docbook/tutorial/en/master.xml 2008-03-08 11:34:54 UTC (rev 5403)
@@ -175,7 +175,7 @@
<orderedlist>
<listitem>Set up the Fqns you need. In the BeanShell pane, create 3 Fqn variables:
- <programlisting><![CDATA[
+ <programlisting role="JAVA"><![CDATA[
childFqn1 = Fqn.fromString("/child1");
childFqn2 = Fqn.fromString("/child2");
@@ -186,7 +186,7 @@
<listitem>
Create child nodes under the root node.
- <programlisting><![CDATA[
+ <programlisting role="JAVA"><![CDATA[
child1 = root.addChild(childFqn1);
child2 = root.addChild(childFqn2);
@@ -197,7 +197,7 @@
<listitem>
Query the nodes
- <programlisting><![CDATA[
+ <programlisting role="JAVA"><![CDATA[
root.hasChild(childFqn1); // should return true
child2.hasChild(childFqn3.getLastElement()); // should return true
@@ -210,7 +210,7 @@
<listitem>
Put some data in the nodes.
- <programlisting><![CDATA[
+ <programlisting role="JAVA"><![CDATA[
child1.put("key1", "value1");
child1.put("key2", "value2");
@@ -227,7 +227,7 @@
<listitem>
Query some of the data.
- <programlisting><![CDATA[
+ <programlisting role="JAVA"><![CDATA[
child1.getKeys();
child2.getData();
@@ -239,7 +239,7 @@
<listitem>
Remove some data in the nodes.
- <programlisting><![CDATA[
+ <programlisting role="JAVA"><![CDATA[
child1.remove("key1");
child2.remove("key3");
@@ -251,7 +251,7 @@
<listitem>
Delete nodes
- <programlisting><![CDATA[
+ <programlisting role="JAVA"><![CDATA[
root.removeChild(childFqn1); // will also remove any data held under child1
root.removeChild(childFqn2); // will recursively remove child3 as well.
@@ -292,7 +292,7 @@
replication only occurs on transaction boundaries. Try rolling back a few transactions as well, to see how
nothing gets replicated in these cases.
Below is the sample code for managing transactions:
- <programlisting><![CDATA[
+ <programlisting role="JAVA"><![CDATA[
tm = cache.getTransactionManager();
tm.begin();
Modified: core/trunk/src/main/docbook/userguide/en/modules/basic_api.xml
===================================================================
--- core/trunk/src/main/docbook/userguide/en/modules/basic_api.xml 2008-03-07 17:39:36 UTC (rev 5402)
+++ core/trunk/src/main/docbook/userguide/en/modules/basic_api.xml 2008-03-08 11:34:54 UTC (rev 5403)
@@ -90,7 +90,7 @@
a cache, using the default configuration values:
</para>
- <programlisting>
+ <programlisting role="JAVA">
CacheFactory factory = DefaultCacheFactory.getInstance();
Cache cache = factory.createCache();
</programlisting>
@@ -101,7 +101,7 @@
parse a configuration file on the classpath:
</para>
- <programlisting>
+ <programlisting role="JAVA">
CacheFactory factory = DefaultCacheFactory.getInstance();
Cache cache = factory.createCache("cache-configuration.xml");
</programlisting>
@@ -111,7 +111,7 @@
the cache, and instead do it ourselves:
</para>
- <programlisting>
+ <programlisting role="JAVA">
CacheFactory factory = DefaultCacheFactory.getInstance();
Cache cache = factory.createCache("cache-configuration.xml", false);
Configuration config = cache.getConfiguration();
@@ -135,7 +135,7 @@
in the cache and then do some
simple reads and writes to that node.
</para>
- <programlisting>
+ <programlisting role="JAVA">
// Let's get ahold of the root node.
Node rootNode = cache.getRoot();
@@ -181,7 +181,7 @@
as an argument:
</para>
- <programlisting>
+ <programlisting role="JAVA">
Fqn peterGriffinFqn = Fqn.fromString("/griffin/peter");
cache.put(peterGriffinFqn, "isCartoonCharacter", Boolean.TRUE);
@@ -243,7 +243,7 @@
most commonly used approaches to creating an Fqn:
</para>
- <programlisting>
+ <programlisting role="JAVA">
<![CDATA[
// Create an Fqn pointing to node 'Joe' under parent node 'Smith'
// under the 'people' section of the tree
@@ -263,14 +263,14 @@
<para>Note that</para>
<para>
- <programlisting><![CDATA[Fqn<String> f = new Fqn<String>("/a/b/c");]]></programlisting>
+ <programlisting role="JAVA"><![CDATA[Fqn<String> f = new Fqn<String>("/a/b/c");]]></programlisting>
</para>
<para>is
<emphasis>not</emphasis>
the same as
</para>
<para>
- <programlisting><![CDATA[Fqn<String> f = Fqn.fromString("/a/b/c");]]></programlisting>
+ <programlisting role="JAVA"><![CDATA[Fqn<String> f = Fqn.fromString("/a/b/c");]]></programlisting>
</para>
<para>
@@ -305,7 +305,7 @@
resources like the JGroups channel are properly cleaned up.
</para>
- <programlisting>
+ <programlisting role="JAVA">
cache.stop();
cache.destroy();
</programlisting>
@@ -589,7 +589,7 @@
</para>
<para>
Example:
- <programlisting><![CDATA[
+ <programlisting role="JAVA"><![CDATA[
@CacheListener
public class MyListener
Modified: core/trunk/src/main/docbook/userguide/en/modules/cache_loaders.xml
===================================================================
--- core/trunk/src/main/docbook/userguide/en/modules/cache_loaders.xml 2008-03-07 17:39:36 UTC (rev 5402)
+++ core/trunk/src/main/docbook/userguide/en/modules/cache_loaders.xml 2008-03-08 11:34:54 UTC (rev 5403)
@@ -147,7 +147,7 @@
details.
</para>
- <programlisting>
+ <programlisting role="XML">
<![CDATA[
...
@@ -371,7 +371,7 @@
.
</para>
- <para>
+ <para>
Optionally, within the
<literal>singletonStore</literal>
element, you can define a
@@ -432,7 +432,7 @@
<literal>PushStateException</literal>
if exceeded. Default value is 20000.
</para>
-
+
<para>
<emphasis role="bold">Note on using the
<literal>singletonStore</literal>
@@ -801,7 +801,7 @@
</para>
<para>
- <programlisting>
+ <programlisting role="XML">
<![CDATA[
<attribute name="CacheLoaderConfiguration">
<config>
@@ -842,7 +842,7 @@
the name of an existing data source can be given:
</para>
- <programlisting>
+ <programlisting role="XML">
<![CDATA[
<attribute name="CacheLoaderConfiguration">
<config>
@@ -867,7 +867,7 @@
<para>Cconfiguration example for a cache loader using c3p0 JDBC connection pooling:</para>
- <programlisting>
+ <programlisting role="XML">
<![CDATA[
<attribute name="CacheLoaderConfiguration">
<config>
@@ -935,17 +935,24 @@
to the TcpCacheServer is lost.
</para>
- <para>The TcpDelegatingCacheLoader is configured with the host and port of the remote TcpCacheServer, and uses this to communicate to
- it. In addition, 2 new optional parameters are used to control transparent reconnecting to the TcpCacheServer.
- The <literal>timeout</literal> property (defaults to 5000) specifies the length of time the cache loader must continue
- retrying to connect to the TcpCacheServer before giving up and throwing an exception. The <literal>reconnectWaitTime</literal>
- (defaults to 500) is how long the cache loader should wait before attempting a reconnect if it detects a communication failure.
- The last two parameters can be used to add a level of fault tolerance to the cache loader, do deal with TcpCacheServer restarts.
+ <para>The TcpDelegatingCacheLoader is configured with the host and port of the remote TcpCacheServer, and uses
+ this to communicate to
+ it. In addition, 2 new optional parameters are used to control transparent reconnecting to the
+ TcpCacheServer.
+ The
+ <literal>timeout</literal>
+ property (defaults to 5000) specifies the length of time the cache loader must continue
+ retrying to connect to the TcpCacheServer before giving up and throwing an exception. The
+ <literal>reconnectWaitTime</literal>
+ (defaults to 500) is how long the cache loader should wait before attempting a reconnect if it detects a
+ communication failure.
+ The last two parameters can be used to add a level of fault tolerance to the cache loader, do deal with
+ TcpCacheServer restarts.
</para>
<para>The configuration looks as follows:</para>
- <programlisting>
+ <programlisting role="XML">
<![CDATA[
<attribute name="CacheLoaderConfiguration">
<config>
@@ -1075,64 +1082,64 @@
When passivation is used, only the first cache loader configured is
used and all others are ignored.
</para>
-
+
<section>
- <title>Cache Loader Behavior with Passivation Disabled vs. Enabled</title>
-
- <para>
- When passivation is disabled, whenever an element is modified, added or
- removed, then that modification is persisted in the backend store via
- the cache loader. There is no direct relationship between eviction and
- cache loading. If you don't use eviction, what's in the persistent store
- is basically a copy of what's in memory. If you do use eviction, what's
- in the persistent store is basically a superset of what's in memory
- (i.e. it includes nodes that have been evicted from memory).
- </para>
-
- <para>
- When passivation is enabled, there is a direct relationship between
- eviction and the cache loader. Writes to the persistent store via the
- cache loader only occur as part of the eviction process. Data is deleted
- from the persistent store when the application reads it back into
- memory. In this case, what's in memory and what's in the persistent
- store are two subsets of the total information set, with no intersection between the subsets.
- </para>
-
- <para>
- Following is a simple example, showing what state is in RAM and in the
- persistent store after each step of a 6 step process:
- </para>
-
+ <title>Cache Loader Behavior with Passivation Disabled vs. Enabled</title>
+
+ <para>
+ When passivation is disabled, whenever an element is modified, added or
+ removed, then that modification is persisted in the backend store via
+ the cache loader. There is no direct relationship between eviction and
+ cache loading. If you don't use eviction, what's in the persistent store
+ is basically a copy of what's in memory. If you do use eviction, what's
+ in the persistent store is basically a superset of what's in memory
+ (i.e. it includes nodes that have been evicted from memory).
+ </para>
+
+ <para>
+ When passivation is enabled, there is a direct relationship between
+ eviction and the cache loader. Writes to the persistent store via the
+ cache loader only occur as part of the eviction process. Data is deleted
+ from the persistent store when the application reads it back into
+ memory. In this case, what's in memory and what's in the persistent
+ store are two subsets of the total information set, with no intersection between the subsets.
+ </para>
+
+ <para>
+ Following is a simple example, showing what state is in RAM and in the
+ persistent store after each step of a 6 step process:
+ </para>
+
<orderedlist>
<listitem>Insert /A</listitem>
- <listitem>Insert /B</listitem>
- <listitem>Eviction thread runs, evicts /A</listitem>
- <listitem>Read /A</listitem>
- <listitem>Eviction thread runs, evicts /B</listitem>
- <listitem>Remove /B</listitem>
- </orderedlist>
-
- <para> When passivation is disabled:</para>
- <programlisting>
-1) RAM: /A Disk: /A
-2) RAM: /A, /B Disk: /A, /B
-3) RAM: /B Disk: /A, /B
-4) RAM: /A, /B Disk: /A, /B
-5) RAM: /A Disk: /A, /B
-6) RAM: /A Disk: /A
- </programlisting>
-
- <para>When passivation is enabled:</para>
- <programlisting>
-1) RAM: /A Disk:
-2) RAM: /A, /B Disk:
-3) RAM: /B Disk: /A
-4) RAM: /A, /B Disk:
-5) RAM: /A Disk: /B
-6) RAM: /A Disk:
- </programlisting>
+ <listitem>Insert /B</listitem>
+ <listitem>Eviction thread runs, evicts /A</listitem>
+ <listitem>Read /A</listitem>
+ <listitem>Eviction thread runs, evicts /B</listitem>
+ <listitem>Remove /B</listitem>
+ </orderedlist>
+
+ <para>When passivation is disabled:</para>
+ <programlisting>
+ 1) RAM: /A Disk: /A
+ 2) RAM: /A, /B Disk: /A, /B
+ 3) RAM: /B Disk: /A, /B
+ 4) RAM: /A, /B Disk: /A, /B
+ 5) RAM: /A Disk: /A, /B
+ 6) RAM: /A Disk: /A
+ </programlisting>
+
+ <para>When passivation is enabled:</para>
+ <programlisting>
+ 1) RAM: /A Disk:
+ 2) RAM: /A, /B Disk:
+ 3) RAM: /B Disk: /A
+ 4) RAM: /A, /B Disk:
+ 5) RAM: /A Disk: /B
+ 6) RAM: /A Disk:
+ </programlisting>
</section>
-
+
</section>
<section>
@@ -1218,15 +1225,16 @@
node in the cluster interacts with a backend store via its
cache loader. All other nodes perform in-memory replication. The idea
here is all application state is kept in memory in each node, with
- the existence of multiple caches making the data highly available.
- (This assumes that a client that needs the data is able to somehow
- fail over from one cache to another.) The single persistent backend
- store then provides a backup copy of the data in case all caches in
+ the existence of multiple caches making the data highly available.
+ (This assumes that a client that needs the data is able to somehow
+ fail over from one cache to another.) The single persistent backend
+ store then provides a backup copy of the data in case all caches in
the cluster fail or need to be restarted.
</para>
<para>
- Note that here it may make sense for the cache loader to store
- changes asynchronously, that is <emphasis>not</emphasis>
+ Note that here it may make sense for the cache loader to store
+ changes asynchronously, that is
+ <emphasis>not</emphasis>
on the caller's thread, in order not to slow
down the cluster by accessing (for example) a database. This is a
non-issue when using asynchronous replication.
@@ -1235,11 +1243,12 @@
A weakness with this architecture is that the cache with access
to the cache loader becomes a single point of failure. Furthermore,
if the cluster is restarted, the cache with the cache loader must
- be started first (easy to forget). A solution to the first problem
+ be started first (easy to forget). A solution to the first problem
is to configure a cache loader on each node, but set the
- <literal>singletonStore</literal> configuration to
- <literal>true</literal>. With this kind of setup, one but only one
- node will always be writing to a persistent store. However, this
+ <literal>singletonStore</literal>
+ configuration to
+ <literal>true</literal>. With this kind of setup, one but only one
+ node will always be writing to a persistent store. However, this
complicates the restart problem, as before restarting you need
to determine which cache was writing before the shutdown/failure
and then start that cache first.
Modified: core/trunk/src/main/docbook/userguide/en/modules/configuration.xml
===================================================================
--- core/trunk/src/main/docbook/userguide/en/modules/configuration.xml 2008-03-07 17:39:36 UTC (rev 5402)
+++ core/trunk/src/main/docbook/userguide/en/modules/configuration.xml 2008-03-08 11:34:54 UTC (rev 5403)
@@ -64,7 +64,7 @@
<para>
Here is a simple example configuration file:
</para>
- <programlisting>
+ <programlisting role="XML">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
@@ -154,7 +154,7 @@
classpath:
</para>
- <programlisting>
+ <programlisting role="JAVA">
CacheFactory factory = DefaultCacheFactory.getInstance();
Cache cache = factory.createCache("cache-configuration.xml");
</programlisting>
@@ -185,7 +185,7 @@
:
</para>
- <programlisting>
+ <programlisting role="JAVA">
<![CDATA[
Configuration config = new Configuration();
String tmlc = GenericTransactionManagerLookup.class.getName();
@@ -390,7 +390,7 @@
by programmatically obtaining the
<literal>Configuration</literal>
object from the running cache and changing values. E.g.,
- <programlisting>
+ <programlisting role="JAVA">
Configuration liveConfig = cache.getConfiguration();
liveConfig.setLockAcquisitionTimeout(2000);
@@ -420,7 +420,7 @@
</para>
<para>
E.g., to override the default node versioning used with optimistic locking:
- <programlisting>
+ <programlisting role="JAVA">
DataVersion v = new MyCustomDataVersion();
cache.getInvocationContext().getOptionOverrides().setDataVersion(v);
@@ -430,7 +430,7 @@
</para>
<para>
E.g., to suppress replication of a put call in a REPL_SYNC cache:
- <programlisting>
+ <programlisting role="JAVA">
Node node = cache.getChild(Fqn.fromString("/a/b/c"));
cache.getInvocationContext().getOptionOverrides().setLocalOnly(true);
Modified: core/trunk/src/main/docbook/userguide/en/modules/configuration_reference.xml
===================================================================
--- core/trunk/src/main/docbook/userguide/en/modules/configuration_reference.xml 2008-03-07 17:39:36 UTC (rev 5402)
+++ core/trunk/src/main/docbook/userguide/en/modules/configuration_reference.xml 2008-03-08 11:34:54 UTC (rev 5403)
@@ -7,7 +7,7 @@
configurations
shipped with the JBoss Cache distribution and tweak according to your needs rather than write one from scratch.
</para>
- <programlisting>
+ <programlisting role="XML">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
Modified: core/trunk/src/main/docbook/userguide/en/modules/deployment.xml
===================================================================
--- core/trunk/src/main/docbook/userguide/en/modules/deployment.xml 2008-03-07 17:39:36 UTC (rev 5402)
+++ core/trunk/src/main/docbook/userguide/en/modules/deployment.xml 2008-03-08 11:34:54 UTC (rev 5403)
@@ -106,7 +106,7 @@
the cache:
</para>
- <programlisting>
+ <programlisting role="JAVA">
<![CDATA[
MBeanServer server = MBeanServerLocator.locateJBoss();
ObjectName on = new ObjectName("jboss.cache:service=Cache");
@@ -186,7 +186,7 @@
installation, you can find several more examples.
</para>
- <programlisting>
+ <programlisting role="XML">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
@@ -445,7 +445,7 @@
constructor.
</para>
- <programlisting>
+ <programlisting role="JAVA">
CacheFactory factory = DefaultCacheFactory.getInstance();
// Build but don't start the cache
// (although it would work OK if we started it)
@@ -483,7 +483,7 @@
:
</para>
- <programlisting>
+ <programlisting role="JAVA">
Configuration config = buildConfiguration(); // whatever it does
CacheJmxWrapperMBean wrapper = new CacheJmxWrapper(config);
@@ -542,7 +542,7 @@
bean:
</para>
- <programlisting>
+ <programlisting role="XML">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
@@ -608,7 +608,7 @@
:
</para>
- <programlisting>
+ <programlisting role="XML">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
@@ -763,7 +763,7 @@
JBoss AS environment. In this example, the client uses a filter to specify which events are of interest.
</para>
- <programlisting>
+ <programlisting role="JAVA">
<![CDATA[
MyListener listener = new MyListener();
NotificationFilterSupport filter = null;
@@ -794,7 +794,7 @@
</programlisting>
<para>The following is the simple notification listener implementation used in the previous example.</para>
- <programlisting>
+ <programlisting role="XML">
<![CDATA[
private class MyListener implements NotificationListener, Serializable
{
Modified: core/trunk/src/main/docbook/userguide/en/modules/eviction_policies.xml
===================================================================
--- core/trunk/src/main/docbook/userguide/en/modules/eviction_policies.xml 2008-03-07 17:39:36 UTC (rev 5402)
+++ core/trunk/src/main/docbook/userguide/en/modules/eviction_policies.xml 2008-03-08 11:34:54 UTC (rev 5403)
@@ -16,7 +16,7 @@
<title>Basic Configuration</title>
<para>
The basic eviction policy configuration element looks like:
- <programlisting>
+ <programlisting role="XML">
<![CDATA[
...
@@ -107,7 +107,9 @@
<literal>maxNodes</literal>
parameter which defines
how many nodes can exist in the region before it chooses to start evicting nodes. See the javadocs for each
- policy for a list of allowed parameters. It also defines a <literal>minTimeToLiveSeconds</literal> parameter,
+ policy for a list of allowed parameters. It also defines a
+ <literal>minTimeToLiveSeconds</literal>
+ parameter,
which defines a minimum time a node must exist in memory before being considered for eviction.
</para>
@@ -139,18 +141,27 @@
<section>
<title>Resident Nodes</title>
<para>
- Nodes marked as resident (using <literal>Node.setResident()</literal> API) will be ignored by the eviction policies both when checking whether to trigger
- the eviction and when proceeding with the actual eviction of nodes. E.g. if a region is configured to have a maximum of 10 nodes, resident nodes won't be
- counted when deciding whether to evict nodes in that region. In addition, resident nodes will not be considered for eviction when the region's eviction
- threshold is reached.
+ Nodes marked as resident (using
+ <literal>Node.setResident()</literal>
+ API) will be ignored by the eviction policies both when checking whether to trigger
+ the eviction and when proceeding with the actual eviction of nodes. E.g. if a region is configured to have a
+ maximum of 10 nodes, resident nodes won't be
+ counted when deciding whether to evict nodes in that region. In addition, resident nodes will not be
+ considered for eviction when the region's eviction
+ threshold is reached.
</para>
<para>
- In order to mark a node as resident the <literal>Node.setResident()</literal> API should be used. By default, the newly created nodes are not resident.
- The <literal>resident</literal> attribute of a node is neither replicated, persisted nor transaction-aware.
+ In order to mark a node as resident the
+ <literal>Node.setResident()</literal>
+ API should be used. By default, the newly created nodes are not resident.
+ The
+ <literal>resident</literal>
+ attribute of a node is neither replicated, persisted nor transaction-aware.
</para>
<para>
- A sample use case for resident nodes would be ensuring "path" nodes don't add "noise" to an eviction policy. E.g.
- <programlisting>
+ A sample use case for resident nodes would be ensuring "path" nodes don't add "noise" to an eviction policy.
+ E.g.
+ <programlisting role="JAVA">
<![CDATA[
...
Map lotsOfData = generateData();
@@ -160,13 +171,24 @@
...
]]>
</programlisting>
- In this example, the nodes <literal>/a</literal> and <literal>/a/b</literal> are paths which exist solely to
- support the existence of node <literal>/a/b/c</literal> and don't hold any data themselves. As such, they are
- good candidates for being marked as resident. This would lead to better memory management as no eviction events would be
- generated when accessing <literal>/a</literal> and <literal>/a/b</literal>.
+ In this example, the nodes
+ <literal>/a</literal>
+ and
+ <literal>/a/b</literal>
+ are paths which exist solely to
+ support the existence of node
+ <literal>/a/b/c</literal>
+ and don't hold any data themselves. As such, they are
+ good candidates for being marked as resident. This would lead to better memory management as no eviction
+ events would be
+ generated when accessing
+ <literal>/a</literal>
+ and<literal>/a/b</literal>.
</para>
<para>
- N.B. when adding attributes to a resident node, e.g. <literal>cache.put("/a", "k", "v")</literal> in the above example, it would make sense to mark the nodes
+ N.B. when adding attributes to a resident node, e.g.
+ <literal>cache.put("/a", "k", "v")</literal>
+ in the above example, it would make sense to mark the nodes
as non-resident again and let them be considered for eviction..
</para>
</section>
@@ -200,7 +222,7 @@
:
</para>
- <programlisting>
+ <programlisting role="JAVA">
Fqn fqn = Fqn.fromString("/org/jboss/fifo");
// Create a configuration for an LRUPolicy
@@ -248,7 +270,7 @@
<listitem>
<literal>minTimeToLiveSeconds</literal>
- the minimum amount of time a node must be allowed to live after being accessed before it is allowed to
- be considered for eviction. 0 denotes that this feature is disabled, which is the default value.
+ be considered for eviction. 0 denotes that this feature is disabled, which is the default value.
</listitem>
</itemizedlist>
</section>
@@ -273,7 +295,7 @@
<listitem>
<literal>minTimeToLiveSeconds</literal>
- the minimum amount of time a node must be allowed to live after being accessed before it is allowed to
- be considered for eviction. 0 denotes that this feature is disabled, which is the default value.
+ be considered for eviction. 0 denotes that this feature is disabled, which is the default value.
</listitem>
</itemizedlist>
</section>
@@ -301,7 +323,7 @@
<listitem>
<literal>minTimeToLiveSeconds</literal>
- the minimum amount of time a node must be allowed to live after being accessed before it is allowed to
- be considered for eviction. 0 denotes that this feature is disabled, which is the default value.
+ be considered for eviction. 0 denotes that this feature is disabled, which is the default value.
</listitem>
</itemizedlist>
</section>
@@ -350,7 +372,7 @@
<listitem>
<literal>minTimeToLiveSeconds</literal>
- the minimum amount of time a node must be allowed to live after being accessed before it is allowed to
- be considered for eviction. 0 denotes that this feature is disabled, which is the default value.
+ be considered for eviction. 0 denotes that this feature is disabled, which is the default value.
</listitem>
</itemizedlist>
@@ -405,7 +427,7 @@
<para>
The following listing shows how the expiration date is indicated and how the
policy is applied:
- <programlisting>
+ <programlisting role="JAVA">
<![CDATA[
Cache cache = DefaultCacheFactory.createCache();
Fqn fqn1 = Fqn.fromString("/node/1");
@@ -451,7 +473,7 @@
<listitem>
<literal>minTimeToLiveSeconds</literal>
- the minimum amount of time a node must be allowed to live after being accessed before it is allowed to
- be considered for eviction. 0 denotes that this feature is disabled, which is the default value.
+ be considered for eviction. 0 denotes that this feature is disabled, which is the default value.
</listitem>
</itemizedlist>
</section>
Modified: core/trunk/src/main/docbook/userguide/en/modules/replication.xml
===================================================================
--- core/trunk/src/main/docbook/userguide/en/modules/replication.xml 2008-03-07 17:39:36 UTC (rev 5402)
+++ core/trunk/src/main/docbook/userguide/en/modules/replication.xml 2008-03-08 11:34:54 UTC (rev 5403)
@@ -361,7 +361,7 @@
<title>Configuration</title>
<para>
- <programlisting>
+ <programlisting role="XML">
<![CDATA[
<!-- Buddy Replication config -->
<attribute name="BuddyReplicationConfig">
Modified: core/trunk/src/main/docbook/userguide/en/modules/transactions.xml
===================================================================
--- core/trunk/src/main/docbook/userguide/en/modules/transactions.xml 2008-03-07 17:39:36 UTC (rev 5402)
+++ core/trunk/src/main/docbook/userguide/en/modules/transactions.xml 2008-03-08 11:34:54 UTC (rev 5403)
@@ -162,7 +162,9 @@
</para>
<para>
In addition to the above, in version 2.1.0 and above, JBoss Cache offers the ability to override this
- configuration on a per-node basis. See <literal>Node.setLockForChildInsertRemove()</literal> and it's
+ configuration on a per-node basis. See
+ <literal>Node.setLockForChildInsertRemove()</literal>
+ and it's
corresponding javadocs for details.
</para>
</section>
@@ -240,7 +242,7 @@
<section>
<title>Configuration</title>
Optimistic locking is enabled by using the NodeLockingScheme XML attribute, and setting it to "OPTIMISTIC":
- <programlisting>
+ <programlisting role="XML">
<![CDATA[
...
<!--
@@ -252,12 +254,19 @@
...
]]>
</programlisting>
- It is generally advisable that if you have an eviction policy defined along with optimistic locking, you define
- the eviction policy's <literal>minTimeToLiveSeconds</literal> parameter to be slightly greater than the transaction
- timeout value set in your transaction manager. This ensures that data versions in the cache are not evicted
- while transactions are in progress<footnote>
- <para>See <ulink url="http://jira.jboss.com/jira/browse/JBCACHE-1155">JBCACHE-1155</ulink></para>
- </footnote>.
+ It is generally advisable that if you have an eviction policy defined along with optimistic locking, you
+ define
+ the eviction policy's
+ <literal>minTimeToLiveSeconds</literal>
+ parameter to be slightly greater than the transaction
+ timeout value set in your transaction manager. This ensures that data versions in the cache are not evicted
+ while transactions are in progress
+ <footnote>
+ <para>See
+ <ulink url="http://jira.jboss.com/jira/browse/JBCACHE-1155">JBCACHE-1155</ulink>
+ </para>
+ </footnote>
+ .
</section>
</section>
</section>
@@ -293,14 +302,15 @@
</listitem>
</orderedlist>
<para>
- In order to do this, the cache has to be provided with a
- reference to environment's
+ In order to do this, the cache has to be provided with a
+ reference to environment's
<literal>javax.transaction.TransactionManager</literal>
- . This is usually done by configuring the cache
+ . This is usually done by configuring the cache
with the class name of an implementation of the
<literal>TransactionManagerLookup</literal>
interface. When the cache starts, it will create an instance of this
- class and invoke its <literal>getTransactionManager()</literal>
+ class and invoke its
+ <literal>getTransactionManager()</literal>
method, which returns a reference to the
<literal>TransactionManager</literal>
.
@@ -328,24 +338,34 @@
- is also provided, primarily for unit tests. Being a dummy, this is just for demo and testing purposes and is
not recommended for production use.
</para>
-
+
<para>
- An alternative to configuring a <literal>TransactionManagerLookup</literal>
- is to programatically inject a reference to the <literal>TransactionManager</literal>
- into the <literal>Configuration</literal> object's <literal>RuntimeConfig</literal> element:
+ An alternative to configuring a
+ <literal>TransactionManagerLookup</literal>
+ is to programatically inject a reference to the
+ <literal>TransactionManager</literal>
+ into the
+ <literal>Configuration</literal>
+ object's
+ <literal>RuntimeConfig</literal>
+ element:
</para>
-
- <programlisting>
+
+ <programlisting role="JAVA">
TransactionManager tm = getTransactionManager(); // magic method
- cache.getConfiguration().getRuntimeConfig().setTransactionManager(tm);
+ cache.getConfiguration().getRuntimeConfig().setTransactionManager(tm);
</programlisting>
-
+
<para>
- Injecting the <literal>TransactionManager</literal> is the recommended
- approach when the <literal>Configuration</literal> is built by some sort of
+ Injecting the
+ <literal>TransactionManager</literal>
+ is the recommended
+ approach when the
+ <literal>Configuration</literal>
+ is built by some sort of
IOC container that already has a reference to the TM.
</para>
-
+
<para>When the transaction commits, we initiate either a one- two-phase commit
protocol. See
<link linkend="replication.tx">replicated caches and transactions</link>
More information about the jbosscache-commits
mailing list