Author: manik.surtani(a)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... - </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... + </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>