October 2008 - jbosscache-commits

by jbosscache-commits＠lists.jboss.org

Author: manik.surtani(a)jboss.com Date: 2008-10-20 17:49:58 -0400 (Mon, 20 Oct 2008) New Revision: 6988 Added: core/tags/2.2.1.GA/ Log: Copied: core/tags/2.2.1.GA (from rev 6987, core/branches/2.2.X)

17 years

1
0
0 / 0

JBoss Cache SVN: r6987 - core/trunk/src/main/docbook/userguide/en/modules.

by jbosscache-commits＠lists.jboss.org

Author: manik.surtani(a)jboss.com Date: 2008-10-20 17:43:47 -0400 (Mon, 20 Oct 2008) New Revision: 6987 Modified: core/trunk/src/main/docbook/userguide/en/modules/eviction_policies.xml Log: More doc updates Modified: core/trunk/src/main/docbook/userguide/en/modules/eviction_policies.xml =================================================================== --- core/trunk/src/main/docbook/userguide/en/modules/eviction_policies.xml 2008-10-20 13:46:58 UTC (rev 6986) +++ core/trunk/src/main/docbook/userguide/en/modules/eviction_policies.xml 2008-10-20 21:43:47 UTC (rev 6987) @@ -1,141 +1,116 @@ <chapter id="eviction_policies"> - <title>Eviction Policies</title> + <title>Eviction</title> <para> - Eviction policies control JBoss Cache's memory management by managing how many nodes are allowed to be stored in - memory and their life spans. Memory constraints on servers mean cache cannot grow indefinitely, so policies - need to be in place to restrict the size of the cache. Eviction policies are most often used alongside - <link linkend="cache_loaders">cache loaders</link> - <link linkend="cache_loaders">cache loaders</link> - . + Eviction controls JBoss Cache's memory management by restricting how many nodes are allowed to be stored in + memory, and for how long. Memory constraints on servers mean caches cannot grow indefinitely, so eviction + needs to occur to prevent out of memory errors. Eviction is most often used alongside <link linkend="cache_loaders">cache loaders</link>. </para> - <section> - <title>Configuring Eviction Policies</title> + <section id="eviction.design"> + <title>Design</title> + <para> + Eviction in JBoss Cache is designed around four concepts: + <itemizedlist> + <listitem>1. Collecting statistics</listitem> + <listitem>2. Determining which nodes to evict</listitem> + <listitem>3. How nodes are evicted</listitem> + <listitem>4. Eviction threads.</listitem> + </itemizedlist> + In addition, Regions play a key role in eviction, as eviction is always configured on a per-region basis so that + different subtrees in the cache can have different eviction characteristics. + </para> + <section> - <title>Basic Configuration</title> + <title>Collecting Statistics</title> <para> - The basic eviction policy configuration element looks like: + This is done on the caller's thread whenever anyone interacts with the cache. If eviction is enabled, an + <literal>EvictionInterceptor</literal> is added to the interceptor chain and events are recorded in an + event queue. Events are denoted by the <literal>EvictionEvent</literal> class. Event queues are held on + specific Regions so each region has its own event queue. </para> - <programlisting role="XML"><![CDATA[ - ... - - <attribute name="EvictionConfig"> - <config> - <attribute name="wakeUpIntervalSeconds">3</attribute> - -  - <attribute name="eventQueueSize">100000</attribute> - -  - <attribute name="policyClass">org.jboss.cache.eviction.LRUPolicy</attribute> - -  - <region name="/_default_"> - <attribute name="maxNodes">100</attribute> - </region> - -  - <region name="/org/jboss/data" policyClass="org.jboss.cache.eviction.LRUPolicy"> - <attribute name="maxNodes">250</attribute> - <attribute name="minTimeToLiveSeconds">10</attribute> - </region> - -  - <region name="/org/jboss/test/data" eventQueueSize="500000"> - <attribute name="maxNodes">60000</attribute> - </region> - - </config> - </attribute> - - ... -]]></programlisting> <para> - <itemizedlist> - <listitem> - <literal>wakeUpIntervalSeconds</literal> - - this required parameter defines how often the eviction thread runs - </listitem> - <listitem> - <literal>eventQueueSize</literal> - - this optional parameter defines the size of the queue which holds eviction events. If your eviction - thread does not run often enough, you may need to increase this. This can be overridden on a - per-region basis. - </listitem> - <listitem> - <literal>policyClass</literal> - - this is required, unless you set individual policyClass attributes on each and every region. This - defines the eviction policy to use if one is not defined for a region. - </listitem> - </itemizedlist> + This aspect of eviction is not configurable, except that the <literal>EvictionInterceptor</literal> is either + added to the interceptor chain or not, depending on whether eviction is enabled. + </para> + </section> + <section> + <title>Determining Which Nodes to Evict</title> + <para> + An <literal>EvictionAlgorithm</literal> implementation processes the eviction queue to decide which nodes to + evict. JBoss Cache ships with a number of implementations, including <literal>FIFOAlgorithm</literal>, + <literal>LRUAlgorithm</literal>, <literal>LFUAlgorithm</literal>, etc. Each implementation has a corresponding + <literal>EvictionAlgorithmConfig</literal> implementation with configuration details for the algorithm. </para> + <para> + Custom <literal>EvictionAlgorithm</literal> implementations can be provided by implementing the interface + or extending one of the provided implementations. + </para> + <para> + Algorithms are executed by calling its <literal>process()</literal> method and passing in the event queue to + process. This is typically done by calling <literal>Region.processEvictionQueues()</literal>, which will + locate the Algorithm assigned to the region. + </para> </section> + <section> - <title>Eviction Regions</title> + <title>How Nodes are Evicted</title> <para> - The concept of regions and the - <literal>Region</literal> - class were - <link linkend="architecture.regions">visited earlier</link> - when talking about marshalling. Regions also have another use, in that they are used to define the eviction - policy used within the region. In addition to using a region-specific configuration, you can also configure - a default, cache-wide eviction policy for nodes that do not fall into predefined regions or if you do not - wish to define specific regions. It is important to note that when defining regions using the configuration - XML file, all elements of the - <literal>Fqn</literal> - that defines the region are - <literal>java.lang.String</literal> - objects. + Once the <literal>EvictionAlgorithm</literal> decides which nodes to evict, it uses an implementation of + <literal>EvictionActionPolicy</literal> to determine how to evict nodes. This is configurable on a per-region + basis, and defaults to <literal>DefaultEvictionActionPolicy</literal>, which invokes <literal>Cache.evict()</literal> + for each node that needs to be evicted. </para> <para> - Looking at the eviction configuration snippet above, we see that a default region, - <literal>_default_</literal> - , holds attributes - which apply to nodes that do not fall into any of the other regions defined. + JBoss Cache also ships with <literal>RemoveOnEvictActionPolicy</literal>, which calls <literal>Cache.removeNode()</literal> + for each node that needs to be evicted, instead of <literal>Cache.evict()</literal>. </para> <para> - For each region, you can define parameters which affect how the policy which applies to the region chooses - to evict nodes. - In the example above, the - <literal>LRUPolicy</literal> - allows a - <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, - which defines a minimum time a node must exist in memory before being considered for eviction. + Custom <literal>EvictionActionPolicy</literal> implementations can be used as well. </para> + </section> - <section> - <title>Overlapping Eviction Regions</title> + <section> + <title>Eviction threads</title> + <para> + By default, a single cache-wide eviction thread is used to periodically iterate through registered regions + and call <literal>Region.processEvictionQueues()</literal> on each region. The frequency with which this + thread runs can be configured using the <literal>wakeUpInterval</literal> attribute in the <literal>eviction</literal> + configuration element, and defaults to 5000 milliseconds if not specified. + </para> + <para> + The eviction thread can be disabled by setting <literal>wakeUpInterval</literal> to <literal>0</literal>. + This can be useful if you have your own periodic maintenance thread running and would like to iterate through + regions and call <literal>Region.processEvictionQueues()</literal> yourself. + </para> + </section> + </section> + <section id="regions"> + <title>Eviction Regions</title> + <para> + The concept of regions and the <literal>Region</literal> class were + <link linkend="architecture.regions">visited earlier</link> when talking about marshalling. Regions are also + used to define the eviction behavior for nodes within that region. In addition to using a region-specific + configuration, you can also configure default, cache-wide eviction behavior for nodes that do not fall into + predefined regions or if you do not wish to define specific regions. It is important to note that when + defining regions using the configuration XML file, all elements of the <literal>Fqn</literal> that defines + the region are <literal>String</literal> objects. + </para> + <para> + For each region, you can define eviction parameters. + </para> + <para>It's possible to define regions that overlap. In other words, one region can be defined for - <emphasis>/a/b/c</emphasis> - , and another - defined for - <emphasis>/a/b/c/d</emphasis> - (which is just the - <emphasis>d</emphasis> - subtree of the - <emphasis>/a/b/c</emphasis> - sub-tree). + <literal>/a/b/c</literal>, and another defined for <literal>/a/b/c/d</literal> (which is just the + <emphasis>d</emphasis> subtree of the <literal>/a/b/c</literal> sub-tree). The algorithm, in order to handle scenarios like this consistently, will always choose the first region - it encounters. - In this way, if the algorithm needed to decide how to handle - <emphasis>/a/b/c/d/e</emphasis> - , it would start from there and work + it encounters. In this way, if the algorithm needed to decide how to handle node + <literal>/a/b/c/d/e</literal>, it would start from there and work its way up the tree until it hits the first defined region - in this case - <emphasis>/a/b/c/d</emphasis> - . + <literal>/a/b/c/d</literal>. </para> - </section> - - </section> <section> <title>Resident Nodes</title> <para> @@ -190,7 +165,52 @@ as non-resident again and let them be considered for eviction.. </para> </section> + </section> + <section> + <title>Configuring Eviction</title> + <section id="eviction.basic_cfg"> + <title>Basic Configuration</title> + <para> + The basic eviction configuration element looks like: + </para> + <programlisting role="XML"><![CDATA[ + ... + <eviction wakeUpInterval="500" eventQueueSize="100000"> + <default algorithmClass="org.jboss.cache.eviction.LRUAlgorithm"> + <attribute name="maxNodes">5000</attribute> + <attribute name="timeToLive">1000</attribute> + </default> + </eviction> + ... +]]></programlisting> + <para> + <itemizedlist> + <listitem> + <literal>wakeUpInterval</literal> + - this required parameter defines how often the eviction thread runs, in milliseconds. + </listitem> + <listitem> + <literal>eventQueueSize</literal> + - this optional parameter defines the size of the bounded queue which holds eviction events. If your + eviction thread does not run often enough, you may find that the event queue fills up. It may then be + necessary to get your eviction thread to run more frequently, or increase the size of your event queue. + This configuration is just the <emphasis>default</emphasis> event queue size, and can be overridden + in specific eviction regions. If not specified, this defaults to <literal>200000</literal>. + </listitem> + <listitem> + <literal>algorithmClass</literal> + - this is required, unless you set individual <literal>algorithmClass</literal> attributes on each and every region. This + defines the default eviction algorithm to use if one is not defined for a region. + </listitem> + <listitem> + Algorithm configuration attributes - these are specific to the algorithm specified in <literal>algorithmClass</literal>. + See the section specific to the algorithm you are interested in for details. + </listitem> + </itemizedlist> + </para> + </section> + <section> <title>Programmatic Configuration</title> <para> @@ -199,8 +219,7 @@ object entails the use of the <literal>org.jboss.cache.config.EvictionConfig</literal> bean, which is passed into - <literal>Configuration.setEvictionConfig()</literal> - . See the + <literal>Configuration.setEvictionConfig()</literal>. See the <link linkend="configuration">chapter on Configuration</link> for more on building a <literal>Configuration</literal> @@ -210,37 +229,43 @@ <para> The use of simple POJO beans to represent all elements in a cache's configuration also makes it fairly easy to programatically - add eviction regions after the cache is started . For example, + add eviction regions after the cache is started. For example, assume we had an existing cache configured via XML with the EvictionConfig element shown above. Now at runtime we wished to add a new eviction region named "/org/jboss/fifo", using - <literal>LRUPolicy</literal> + <literal>LRUAlgorithm</literal> but a different number of - <literal>maxNodes</literal> - : + <literal>maxNodes</literal>: </para> <programlisting role="JAVA"><![CDATA[ Fqn fqn = Fqn.fromString("/org/jboss/fifo"); // Create a configuration for an LRUPolicy - LRUConfiguration lruc = new LRUConfiguration(); + LRUAlgorithmConfig lruc = new LRUAlgorithmConfig(); lruc.setMaxNodes(10000); + // Create an eviction region config + EvictionRegionConfig erc = new EvictionRegionConfig(fqn, lruc); + // Create the region and set the config Region region = cache.getRegion(fqn, true); - region.setEvictionPolicy(lruc); + region.setEvictionRegionConfig(erc); ]]></programlisting> </section> </section> - <section> + <section id="eviction.shipped"> <title>Shipped Eviction Policies</title> + + This section details the different algorithms shipped with JBoss Cache, and the various configuration parameters + used for each algorithm. + <section> - <title>LRUPolicy - Least Recently Used</title> + <title>LRUAlgorithm - Least Recently Used</title> <para> - <literal>org.jboss.cache.eviction.LRUPolicy</literal> + <literal>org.jboss.cache.eviction.LRUAlgorithm</literal> controls both the node lifetime and age. This policy guarantees a constant order ( <literal>O (1)</literal> ) for @@ -251,22 +276,22 @@ <itemizedlist> <listitem> <literal>maxNodes</literal> - - This is the maximum number of nodes allowed in this region. 0 denotes no limit. + - This is the maximum number of nodes allowed in this region. 0 denotes immediate expiry, -1 denotes no limit. </listitem> <listitem> - <literal>timeToLiveSeconds</literal> - - The amount of time a node is not written to or read (in seconds) before the node is swept away. 0 - denotes no limit. + <literal>timeToLive</literal> + - The amount of time a node is not written to or read (in milliseconds) before the node is swept away. 0 + denotes immediate expiry, -1 denotes no limit. </listitem> <listitem> - <literal>maxAgeSeconds</literal> - - Lifespan of a node (in seconds) regardless of idle time before the node is swept away. 0 denotes no - limit. + <literal>maxAge</literal> + - Lifespan of a node (in milliseconds) regardless of idle time before the node is swept away. 0 + denotes immediate expiry, -1 denotes no limit. </listitem> <listitem> - <literal>minTimeToLiveSeconds</literal> + <literal>minTimeToLive</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. </listitem> @@ -274,10 +299,10 @@ </section> <section> - <title>FIFOPolicy - First In, First Out</title> + <title>FIFOAlgorithm - First In, First Out</title> <para> - <literal>org.jboss.cache.eviction.FIFOPolicy</literal> + <literal>org.jboss.cache.eviction.FIFOAlgorithm</literal> controls the eviction in a proper first in first out order. This policy guarantees a constant order ( <literal>O (1)</literal> @@ -288,10 +313,10 @@ <itemizedlist> <listitem> <literal>maxNodes</literal> - - This is the maximum number of nodes allowed in this region. 0 denotes no limit. + - This is the maximum number of nodes allowed in this region. 0 denotes immediate expiry, -1 denotes no limit. </listitem> <listitem> - <literal>minTimeToLiveSeconds</literal> + <literal>minTimeToLive</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. </listitem> @@ -300,10 +325,10 @@ <section> - <title>MRUPolicy - Most Recently Used</title> + <title>MRUAlgorithm - Most Recently Used</title> <para> - <literal>org.jboss.cache.eviction.MRUPolicy</literal> + <literal>org.jboss.cache.eviction.MRUAlgorithm</literal> controls the eviction in based on most recently used algorithm. The most recently used nodes will be the first to evict with this policy. This policy @@ -316,10 +341,11 @@ <itemizedlist> <listitem> <literal>maxNodes</literal> - - This is the maximum number of nodes allowed in this region. 0 denotes no limit. + - This is the maximum number of nodes allowed in this region. 0 + denotes immediate expiry, -1 denotes no limit. </listitem> <listitem> - <literal>minTimeToLiveSeconds</literal> + <literal>minTimeToLive</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. </listitem> @@ -327,10 +353,10 @@ </section> <section> - <title>LFUPolicy - Least Frequently Used</title> + <title>LFUAlgorithm - Least Frequently Used</title> <para> - <literal>org.jboss.cache.eviction.LFUPolicy</literal> + <literal>org.jboss.cache.eviction.LFUAlgorithm</literal> controls the eviction in based on least frequently used algorithm. The least frequently used nodes will be the first to evict with this policy. Node @@ -356,7 +382,8 @@ <itemizedlist> <listitem> <literal>maxNodes</literal> - - This is the maximum number of nodes allowed in this region. 0 denotes no limit. + - This is the maximum number of nodes allowed in this region. 0 + denotes immediate expiry, -1 denotes no limit. </listitem> <listitem> <literal>minNodes</literal> @@ -368,7 +395,7 @@ algorithm. </listitem> <listitem> - <literal>minTimeToLiveSeconds</literal> + <literal>minTimeToLive</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. </listitem> @@ -377,10 +404,10 @@ </section> <section> - <title>ExpirationPolicy</title> + <title>ExpirationAlgorithm</title> <para> - <literal>org.jboss.cache.eviction.ExpirationPolicy</literal> + <literal>org.jboss.cache.eviction.ExpirationAlgorithm</literal> is a policy that evicts nodes based on an absolute expiration time. The expiration time is indicated using the @@ -418,7 +445,8 @@ </listitem> <listitem> <literal>maxNodes</literal> - - This is the maximum number of nodes allowed in this region. 0 denotes no limit. + - This is the maximum number of nodes allowed in this region. 0 + denotes immediate expiry, -1 denotes no limit. </listitem> </itemizedlist> @@ -449,10 +477,10 @@ </para> </section> <section> - <title>ElementSizePolicy - Eviction based on number of key/value pairs in a node</title> + <title>ElementSizeAlgorithm - Eviction based on number of key/value pairs in a node</title> <para> - <literal>org.jboss.cache.eviction.ElementSizePolicy</literal> + <literal>org.jboss.cache.eviction.ElementSizeAlgorithm</literal> controls the eviction in based on the number of key/value pairs in the node. Nodes The most recently used nodes will be the first to evict with this policy. It has the following configuration parameters: @@ -461,159 +489,20 @@ <itemizedlist> <listitem> <literal>maxNodes</literal> - - This is the maximum number of nodes allowed in this region. 0 denotes no limit. + - This is the maximum number of nodes allowed in this region. 0 + denotes immediate expiry, -1 denotes no limit. </listitem> <listitem> <literal>maxElementsPerNode</literal> - - This is the trigger number of attributes per node for the node to be selected for eviction. 0 denotes - no limit. + - This is the trigger number of attributes per node for the node to be selected for eviction. 0 + denotes immediate expiry, -1 denotes no limit. </listitem> <listitem> - <literal>minTimeToLiveSeconds</literal> + <literal>minTimeToLive</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. </listitem> </itemizedlist> </section> </section> - - <section> - <title>Writing Your Own Eviction Policies</title> - <section> - <title>Eviction Policy Plugin Design</title> - - <para>The design of the JBoss Cache eviction policy framework is based - on an - <literal>EvictionInterceptor</literal> - to handle cache events and relay them back to the eviction - policies. During the cache start up, an - <literal>EvictionInterceptor</literal> - will be added to the cache - interceptor stack if the eviction policy is specified. - Then whenever a node is added, removed, evicted, or visited, the - <literal>EvictionInterceptor</literal> - will maintain state statistics and - information will be relayed to each individual eviction region. - </para> - - <para> - There is a single eviction thread (timer) that will run at a - configured interval. This thread will make calls into each of the policy - providers and inform it of any aggregated adds, - removes and visits (gets) events to the cache during the configured interval. - The eviction thread is responsible for kicking off the eviction policy - processing (a single pass) for each configured eviction cache - region. - </para> - </section> - - <section> - <title>Interfaces to implement</title> - <para>In order to implement an eviction policy, the following interfaces - must be implemented: - <itemizedlist> - <listitem> - <literal>org.jboss.cache.eviction.EvictionPolicy</literal> - </listitem> - <listitem> - <literal>org.jboss.cache.eviction.EvictionAlgorithm</literal> - </listitem> - <listitem> - <literal>org.jboss.cache.eviction.EvictionQueue</literal> - </listitem> - <listitem> - <literal>org.jboss.cache.config.EvictionPolicyConfig</literal> - </listitem> - </itemizedlist> - When compounded - together, each of these interface implementations define all the - underlying mechanics necessary for a complete eviction policy - implementation. - </para> - - <para> - <emphasis>Note that:</emphasis> - </para> - - <itemizedlist> - <listitem> - <para>The - <literal>EvictionPolicyConfig</literal> - implementation - should maintain - getter and setter methods for whatever configuration properties - the policy supports (e.g. for - <literal>LRUConfiguration</literal> - among others there is a - <literal>int getMaxNodes()</literal> - and a - <literal>setMaxNodes(int)</literal> - ). When the "EvictionConfig" section of an XML configuration - is parsed, these properties will be set by reflection. - </para> - </listitem> - </itemizedlist> - - <para>Alternatively, the implementation of a new eviction policy - provider can be simplified by extending - <literal>BaseEvictionPolicy</literal> - and - <literal>BaseEvictionAlgorithm</literal> - . Or for properly sorted EvictionAlgorithms (sorted - in eviction order - see - <literal>LFUAlgorithm</literal> - ) extending - <literal>BaseSortedEvictionAlgorithm</literal> - and implementing - <literal>SortedEvictionQueue</literal> - takes - care of most of the common functionality available in a set of eviction - policy provider classes - </para> - - - <para> - <emphasis>Note that:</emphasis> - </para> - - <itemizedlist> - <listitem> - <para>The - <literal>BaseEvictionAlgorithm</literal> - class maintains a processing - structure. It will process the ADD, REMOVE, and VISIT events queued - by the region first. It also maintains an collection of - items that were not properly evicted during the last go around - because of held locks. That list is pruned. Finally, the - EvictionQueue itself is pruned for entries that should be evicted - based upon the configured eviction rules for the region. - </para> - </listitem> - <listitem> - <para>The - <literal>BaseSortedEvictionAlgorithm</literal> - class will maintain a boolean - through the algorithm processing that will determine if any new - nodes were added or visited. This allows the Algorithm to determine - whether to resort the eviction queue items (in first to evict order) - or to skip the potentially expensive sorting if there have been no - changes to the cache in this region. - </para> - </listitem> - <listitem> - <para>The - <literal>SortedEvictionQueue</literal> - interface defines the contract used by - the - <literal>BaseSortedEvictionAlgorithm</literal> - abstract class that is used to - resort the underlying queue. Again, the queue sorting should be - sorted in first to evict order. The first entry in the list should - evict before the last entry in the queue. The last entry in the - queue should be the last entry that will require eviction. - </para> - </listitem> - </itemizedlist> - </section> - </section> </chapter> \ No newline at end of file

17 years

1
0
0 / 0

JBoss Cache SVN: r6986 - core/branches/2.2.X.

by jbosscache-commits＠lists.jboss.org

Author: bstansberry(a)jboss.com Date: 2008-10-20 09:46:58 -0400 (Mon, 20 Oct 2008) New Revision: 6986 Modified: core/branches/2.2.X/pom.xml Log: Update the JBoss5 profile. Modified: core/branches/2.2.X/pom.xml =================================================================== --- core/branches/2.2.X/pom.xml 2008-10-20 10:55:23 UTC (rev 6985) +++ core/branches/2.2.X/pom.xml 2008-10-20 13:46:58 UTC (rev 6986) @@ -412,7 +412,7 @@ <activeByDefault>false</activeByDefault> </activation> <properties> - <jbosscache-core-version>2.2.0-SNAPSHOT-JBossAS</jbosscache-core-version> + <jbosscache-core-version>2.2.1-SNAPSHOT-JBossAS</jbosscache-core-version> <defaultTestGroup>functional,unit</defaultTestGroup> </properties> <dependencies> @@ -425,7 +425,7 @@ <dependency> <groupId>org.jboss.javaee</groupId> <artifactId>jboss-javaee</artifactId> - <version>5.0.0.CR1</version> + <version>5.0.0.CR2</version> </dependency> <dependency> <groupId>org.jboss</groupId> @@ -440,7 +440,7 @@ <dependency> <groupId>jboss.jbossts</groupId> <artifactId>jbossjta</artifactId> - <version>4.4.0.CR1</version> + <version>4.4.0.GA</version> <scope>test</scope> </dependency> </dependencies>

17 years

1
0
0 / 0

JBoss Cache SVN: r6985 - benchmarks/benchmark-fwk/trunk/cache-products/jbosscache-3.0.0/lib.

by jbosscache-commits＠lists.jboss.org

Author: manik.surtani(a)jboss.com Date: 2008-10-20 06:55:23 -0400 (Mon, 20 Oct 2008) New Revision: 6985 Modified: benchmarks/benchmark-fwk/trunk/cache-products/jbosscache-3.0.0/lib/jbosscache-core.jar benchmarks/benchmark-fwk/trunk/cache-products/jbosscache-3.0.0/lib/jgroups.jar Log: UPdated libs Modified: benchmarks/benchmark-fwk/trunk/cache-products/jbosscache-3.0.0/lib/jbosscache-core.jar =================================================================== (Binary files differ) Modified: benchmarks/benchmark-fwk/trunk/cache-products/jbosscache-3.0.0/lib/jgroups.jar =================================================================== (Binary files differ)

17 years

1
0
0 / 0

JBoss Cache SVN: r6984 - enterprise-docs/tags/JBoss_EAP_4_3/Cache_Tree_Cache_Guide/es-ES.

by jbosscache-commits＠lists.jboss.org

Author: mospina Date: 2008-10-19 21:37:51 -0400 (Sun, 19 Oct 2008) New Revision: 6984 Modified: enterprise-docs/tags/JBoss_EAP_4_3/Cache_Tree_Cache_Guide/es-ES/Cache_loaders.po Log: translation in progress Modified: enterprise-docs/tags/JBoss_EAP_4_3/Cache_Tree_Cache_Guide/es-ES/Cache_loaders.po =================================================================== --- enterprise-docs/tags/JBoss_EAP_4_3/Cache_Tree_Cache_Guide/es-ES/Cache_loaders.po 2008-10-19 09:47:09 UTC (rev 6983) +++ enterprise-docs/tags/JBoss_EAP_4_3/Cache_Tree_Cache_Guide/es-ES/Cache_loaders.po 2008-10-20 01:37:51 UTC (rev 6984) @@ -8,7 +8,7 @@ "Project-Id-Version: Cache_loaders\n" "Report-Msgid-Bugs-To: http://bugs.kde.org\n" "POT-Creation-Date: 2008-09-21 04:43+0000\n" -"PO-Revision-Date: 2008-10-17 11:35+1000\n" +"PO-Revision-Date: 2008-10-20 11:30+1000\n" "Last-Translator: Angela Garcia\n" "Language-Team: <en(a)li.org>\n" "MIME-Version: 1.0\n" @@ -38,7 +38,7 @@ "Whenever a cache element is accessed, and that element is not in the cache " "(e.g. due to eviction or due to server restart), then the cache loader " "transparently loads the element into the cache if found in the backend store." -msgstr "" +msgstr "Cuando se accede a un elemento caché y ese elemento no se encuentra en el caché (por ejemplo, debido a su eliminación o porque se ha reiniciado el servidor) entonces el cargador de caché carga de manera transparente el elemento en el caché si se encuentra en el almacenamiento backend. " #. Tag: para #: Cache_loaders.xml:12 @@ -49,7 +49,7 @@ "used, all modifications created within a transaction are persisted. To this " "end, the cache loader takes part in the two phase commit protocol run by the " "transaction manager." -msgstr "" +msgstr "Cuando se modifica, se añade o se elimina un elemento entonces esa modificación es persistida en el almacenamiento backend a través del cargador de caché. Si se utilizan transacciones entonces todas las modificaciones creadas dentro de una transacción son persistidas. El cargador de caché toma parte en un protocolo de guardar cambios de dos fases ejecutado por el administrador de transacciones. " #. Tag: para #: Cache_loaders.xml:16 @@ -60,7 +60,7 @@ "The goal is to be able to form hierarchical cache topologies, where one " "cache can delegate to another, which in turn may delegate to yet another " "cache." -msgstr "" +msgstr "Actualmente la API cargadora de caché se ve similar a la API TreeCache. En el futuro ambas implementarán la <emphasis>misma</emphasis> interfaz. La meta es poder formar topologias de caché jerárquicas, en donde un caché puede delegar a otro, el cual a su vez puede delegar incluso a otro caché. " #. Tag: para #: Cache_loaders.xml:19 @@ -72,7 +72,7 @@ "of data. When performing writes, all cache loaders are written to (except if " "the ignoreModifications element has been set to true for a specific cache " "loader. See the configuration section below for details." -msgstr "" +msgstr "Desde JBossCache 1.3.0 puede definir varios cargadores de caché en una cadena. El impacto es que el caché mirará todos los cargadores de caché en el orden en que han sido configurados hasta que encunetre un elemento de datos válido, no nulo. Al realizar escrituras, todos los cargadores de caché se escriben (excepto si el elemento ignoreModifications se ha configurado como verdadero para un cargador de caché en especifico. Vea la sección de configuración a continuación para obtener más detalles. " #. Tag: para #: Cache_loaders.xml:22 @@ -81,6 +81,8 @@ "The cache loader interface is defined in org.jboss.cache.loader.CacheLoader " "as follows (edited for brevity):" msgstr "" +"La interfaz del cargador de caché está definido en org.jboss.cache.loader.CacheLoader " +"así (editado para mayor brevedad):" #. Tag: programlisting #: Cache_loaders.xml:25 @@ -441,6 +443,9 @@ "page=JBossCacheCacheLoaders\">this wiki page</ulink> for more discussion on " "this." msgstr "" +"<emphasis role=\"bold\">NOTE:</emphasis> el contrato definido por la interfaz CacheLoader ha cambiado desde JBoss Cache 1.3.0 en adelante, " +"especificamente con el método <literal>get(Fqn fqn)</literal>. Se debe tener bastante cuidado con las implementaciones CacheLoader personalizadas para asegurar de que este nuevo contrato aún se mantiene. Vea el javadoc anterior sobre este método para obtener más detalles o visite esta página wiki <ulink url=\"http://wiki.jboss.org/wiki/Wiki.jsp?" +"page=JBossCacheCacheLoaders\"></ulink> y allí encontrará una discusión más detallada." #. Tag: para #: Cache_loaders.xml:29 @@ -450,6 +455,8 @@ "should also implement the subinterface org.jboss.cache.loader." "ExtendedCacheLoader:" msgstr "" +"Las implementaciones CacheLoader que necesitan soportar transferencia parcial de estado también deben implementar la subinterfaz org.jboss.cache.loader." +"ExtendedCacheLoader:" #. Tag: programlisting #: Cache_loaders.xml:32 @@ -584,6 +591,9 @@ "<literal>ExtendedCacheLoader</literal> unless its " "<literal>FetchPersistentState</literal> property is set to false." msgstr "" +"<emphasis role=\"bold\">NOTA:</emphasis> Si un cargador de caché se utiliza junto con la replicación de compañeros, el cargador de caché tiene que implementar " +"<literal>ExtendedCacheLoader</literal> a menos de que su propiedad " +"<literal>FetchPersistentState</literal> esté configurada como falsa." #. Tag: para #: Cache_loaders.xml:36 @@ -598,12 +608,16 @@ "with custom ExtendedCacheLoader implementations to ensure this new contract " "is still adhered to." msgstr "" +"<emphasis role=\"bold\">NOTA:</emphasis> el contrato definido por la interfaz " +"<literal>ExtendedCacheLoader</literal> ha cambiado desde JBoss " +"Cache 1.4.0 en adelnate, especificamente con el requerimiento de que los datos pasados al método " +"<literal>storeState</literal> sean integrados bajo el subarbol dado incluso si esos datos no se originaron en ese subárbol. Este comportamiento es necesario para soportar apropiadamente la replicación de compañeros. Debe tener mucho cuidado con las implementaciones ExtendedCacheLoader personalizadas para asegurarse de que este nuevo contrato todavía se mantiene." #. Tag: title #: Cache_loaders.xml:40 #, no-c-format msgid "The CacheLoader Interface" -msgstr "" +msgstr "La interfaz CacheLoader" #. Tag: para #: Cache_loaders.xml:41 @@ -615,6 +629,9 @@ "created when the cache is created. Since <literal>CacheLoader</literal> " "extends <literal>Service</literal>," msgstr "" +"La interacción entre JBoss Cache y una implementación CacheLoader es la siguiente. Cuando <literal>CacheLoaderConfiguration</literal> (vea a continuación) no es nulo, una instancia de cada <literal>cacheloader</literal> configurado es " +"creado cuando el caché es creado. Ya que <literal>CacheLoader</literal> " +"extends <literal>Service</literal>," #. Tag: programlisting #: Cache_loaders.xml:44 @@ -649,6 +666,9 @@ "()</literal> and <literal>destroy()</literal> are called when the cache is " "stopped." msgstr "" +"<literal>CacheLoader.create()</literal> y <literal>CacheLoader.start()</" +"literal> son llamados cuando se inicia el caché. De manera correspondiente se llaman a <literal>stop" +"()</literal> y a <literal>destroy()</literal> cuando se detiene el caché." #. Tag: para #: Cache_loaders.xml:48 @@ -658,7 +678,7 @@ "called. The latter can be used to store a reference to the cache, the former " "is used to configure this instance of the CacheLoader. For example, here a " "database CacheLoader could establish a connection to the database." -msgstr "" +msgstr "Después se llama a <literal>setConfig()</literal> y <literal>setCache()</literal>. El último se puede utilizar para almacenar una referencia en el caché y el primero se utiliza para configurar esta instancia del CacheLoader. Por ejemplo, aquí una base de datos CacheLoader puede establecer una conección a la base de datos." #. Tag: para #: Cache_loaders.xml:51 @@ -670,6 +690,8 @@ "set/remove the value immediately. These methods are described as javadoc " "comments in the above interface." msgstr "" +"La interfaz CacheLoader tiene un grupo de métodos que se llaman cuando no se utilizan transacciones: <literal>get()</literal>, <literal>put()</literal>, " +"<literal>remove()</literal> y <literal>removeData()</literal>: obtienen/configuran/eliminna el valor inmediatamente. Estos métodos se describen como comentarios javadoc en la interfaz anterior." #. Tag: para #: Cache_loaders.xml:54 @@ -687,6 +709,9 @@ "the CacheLoader <emphasis>must</emphasis> be able to commit (or rollback) " "the transaction successfully." msgstr "" +"Hay tres métodos que se utilizan con transacciones: <literal>prepare()</literal>, <literal>commit()</literal> y " +"<literal>rollback()</literal>. El método <literal>prepare()</literal> se llama cuando se van a guardar los cambios de una transacción. Tiene un objeto de transacción y una lista de modificaciones como argumento. El objeto de transacciones se puede utilizar como clave para un hashmap de transacciones, en donde los valores son las listas de modificaciones. Cada lista de modificaciones tiene un número de elementos <literal>Modification</" +"literal>, el cual representa los cambios realizados a un caché para una transacción dada. Cuando <literal>prepare()</literal> retorna exitosamente entonces el CacheLoader <emphasis>tiene</emphasis> que poder guardar los cambios (o deshacerlos) de la transacción de manera exitosa." #. Tag: para #: Cache_loaders.xml:57 @@ -698,6 +723,8 @@ "those methods on a loader, the cache will only enlist the loader with the " "TransactionManager on the same transaction." msgstr "" +"Actualmente, el TreeCache se encarga de llamar a prepare(), commit() y " +"rollback() en los CacheLoaders en el momento adecuado. Tenemos la intención de hacer de TreeCache y CacheLoaders recursos XA de manera que en vez de llamar a estos métodos en un cargador, el caché sólo enlistará el cargador con el TransactionManager en la misma transacción." #. Tag: para #: Cache_loaders.xml:60 @@ -706,7 +733,7 @@ "The <literal>commit()</literal> method tells the CacheLoader to commit the " "transaction, and the <literal>rollback()</literal> method tells the " "CacheLoader to discard the changes associated with that transaction." -msgstr "" +msgstr "El método <literal>commit()</literal> le dice al CacheLoader que guarde los cambios de la transacción y el método <literal>rollback()</literal> le dice al CacheLoader que se deshaga de los cambios asociados con esa transacción." #. Tag: para #: Cache_loaders.xml:63 @@ -722,6 +749,9 @@ "the contents of the backend store of an existing member. See below for " "deails." msgstr "" +"Los últimos dos métodos son <literal>loadEntireState()</literal> y " +"<literal>storeEntireState()</literal>. El primer método le pide al CacheLoader que obtenga todo el estado que el almacenamiento backend administra y que lo retorne como un buffer de bytes y el segundo le dice a CacheLoader que reemplace su estado por completo con el argumento buffer de bytes. Estos métodos se utilizan para escenarios en donde cada nodo JBossCache en un clúster tiene su propio almacenamiento local de datos, por ejemplo, una base de datos local, " +"y - cuando un nodo inicia - tenemos que inicializar su almacenamiento backend con el contenido del almacenamiento backend de un miembro existente. Vea a continuación para obtener más detalles." #. Tag: para #: Cache_loaders.xml:66 @@ -736,18 +766,20 @@ "transfers occur when the cache's <literal>activateRegion()</literal> API is " "used and during the formation of buddy groups if buddy replication is used." msgstr "" +"Los métodos <literal>ExtendedCacheLoader</literal> también están relacionados con la transferencia de estado. El método <literal>loadState(Fqn)</literal> se llama cuando el caché está preparando una transferencia parcial de estado -- es decir, la transferencia de sólo la parte del estado del cargador de caché que se encuentra en la raíz del Fqn dado. Luego el método " +"<literal>storeState(byte[], Fqn)</literal> se invoca en el cargador de caché del nodo que está recibiendo la transferencia de estado. Las transferencias parciales de estado ocurren cuando la API <literal>activateRegion()</literal> del caché se utiliza y durante la formación de grupos de compañeros si se utiliza la replicación de compañeros." #. Tag: title #: Cache_loaders.xml:72 #, no-c-format msgid "Configuration via XML" -msgstr "" +msgstr "Configuración por medio de XML" #. Tag: para #: Cache_loaders.xml:73 #, no-c-format msgid "The CacheLoader is configured as follows in the JBossCache XML file:" -msgstr "" +msgstr "El CacheLoader se configura así en el archivo XML JBossCache:" #. Tag: programlisting #: Cache_loaders.xml:76 @@ -891,6 +923,8 @@ "you will have to replace your cache loader configuration with a block " "similar to the one above." msgstr "" +"<emphasis role=\"bold\">Note:</emphasis> En lanzamientos de JBossCache anteriores a " +"1.3.0, el bloque de configuración del cargador de caché solía verse así. Observe que esta forma ha sido <emphasis role=\"deprecated\">DEPRECADA</emphasis> y tendrá que reemplazar su configuración de cargador de caché con un bloque similar al anterior." #. Tag: programlisting #: Cache_loaders.xml:81 @@ -960,13 +994,13 @@ "CacheLoader implementation. (Note that, because of a bug in the properties " "editor in JBoss, backslashes in variables for Windows filenames might not " "get expanded correctly, so replace=\"false\" may be necessary)." -msgstr "" +msgstr "El atributo <literal>CacheLoaderClass</literal> define la clase de la implementación CacheLoader, (observe que debido a un error en el editor de propiedades en JBoss, las barras invertidas en variables para nombres de archivos en Windows no se expanden correctamente así que puede que sea necesario que reemplace=\"false\")." #. Tag: para #: Cache_loaders.xml:86 #, no-c-format msgid "The currently available implementations shipped with JBossCache are:" -msgstr "" +msgstr "Las implementaciones disponibles actualmente que se envían junto con JBossCache son:" #. Tag: para #: Cache_loaders.xml:91 @@ -976,7 +1010,7 @@ "implementation. The <literal><cacheloader><properties></literal> " "element needs to contain a \"location\" property, which maps to a directory " "where the file is located (e.g., \"location=c:\\tmp\")." -msgstr "" +msgstr "<literal>FileCacheLoader</literal>, la cual es una implementación simple basada en el sistema de archivos. El elemento <literal><cacheloader><properties></literal> necesita contener una propiedad \"location\", la cual mapea a un directorio en donde se encuentra el archivo (por ejemplo, \"location=c:\\tmp\")." #. Tag: para #: Cache_loaders.xml:96 @@ -988,6 +1022,8 @@ "which maps to a directory,where the database file for Sleepycat resides (e." "g., \"location=c:\\tmp\")." msgstr "" +"<literal>BdbjeCacheLoader</literal>, la cual es una implementación CacheLoader basada en Sleepycat DB Java Edition. Es necesario que el elemento <literal><cacheloader><" +"properties></literal> contenga una propiedad \"location\", la cual mapee a un directorio, en donde se encuentre el archivo de la base de datos para Sleepycat (por ejemplo, \"location=c:\\tmp\")." #. Tag: para #: Cache_loaders.xml:101 @@ -999,6 +1035,8 @@ "properties needed to connect to the database such as username, password, and " "connection URL. See the section on JDBCCacheLoader for more details." msgstr "" +"<literal>JDBCCacheLoader</literal>, la cual es una implementación CacheLoader utilizando JDBC para acceder a cualquier base de datos relacional. El elemento <literal><" +"cacheloader><properties></literal> contiene un número de propiedades que se necesitan para conectar a la base de datos tal como nombre de usuario, contraseña y URL de conección URL. Para obtener mayor información consulte la sección JDBCCacheLoader." #. Tag: para #: Cache_loaders.xml:106 @@ -1006,7 +1044,7 @@ msgid "" "<literal>LocalDelegatingCacheLoader</literal>, which enables loading from " "and storing to another local (same VM) TreeCache." -msgstr "" +msgstr "<literal>LocalDelegatingCacheLoader</literal>, el cual habilita la descarga y almacenamiento en otro TreeCache local (la misma MV)." #. Tag: para #: Cache_loaders.xml:111 @@ -1016,7 +1054,7 @@ "storing to a remote (different VM) TreeCache using TCP as the transport " "mechanism. This CacheLoader is available in JBossCache version 1.3.0 and " "above." -msgstr "" +msgstr "<literal>TcpDelegatingCacheLoader</literal>, el cual habilida la descarga y el almacenamiento a un TreeCache remoto (una MV diferente) utilizando TCP como el mecanismo de transporte. Este CacheLoader se encuentra disponible en JBossCache versión 1.3.0 y posteriores." #. Tag: para #: Cache_loaders.xml:116 @@ -1032,6 +1070,11 @@ "\"<literal>timeout = 3000</literal>\" would use a timeout value of 3 " "seconds. This CacheLoader is available in JBossCache version 1.3.0 and above." msgstr "" +"<literal>ClusteredCacheLoader</literal>, el cual permite realizar peticiones de otros " +"cachés en el mismo clúster para datos en memoria a través de los mismos protocolos de clustering utilizados para replicar datos. Sin embargo, las escrituras <emphasis role=\"bold\">no</" +"emphasis> 'se almacenan' ya que la replicación se encarga de cualquier actualización que se necesite. Necesita especificar una propiedad llamada \"<literal>timeout</literal>" +"\", un valor largo que le dice al cargador de caché cuántos milisegundos esperar por respuestas del clúster antes de asumir un valor nulo. Por ejemplo, " +"\"<literal>timeout = 3000</literal>\" utilizaría una valor de tiempo de expiración de tres segundos. Este CacheLoader se encuentra disponible en JBossCache versión 1.3.0 y posteriores." #. Tag: para #: Cache_loaders.xml:121 @@ -1042,6 +1085,8 @@ "requires a commercial license if distributed with an application (see http://" "www.sleepycat.com/jeforjbosscache for details)." msgstr "" +"Observe que la implementación Sleepycat es mucho más eficiente que la implementación basada en el sistema de archivos y proporciona garantías transaccionales pero requiere una licensia comercial si se distribuye con una aplicación (consulte http://" +"www.sleepycat.com/jeforjbosscache para obtener más detalles)." #. Tag: para #: Cache_loaders.xml:124 @@ -1049,7 +1094,7 @@ msgid "" "An implementation of CacheLoader has to have an empty constructor due to the " "way it is instantiated." -msgstr "" +msgstr "Una implementación de CacheLoader tiene que tener un constructor vacío debido a la manera en que es instanciado." #. Tag: para #: Cache_loaders.xml:127 @@ -1065,6 +1110,9 @@ "<literal>CacheLoaderConfig</literal> attribute in pre-1.3.0 configurations.</" "emphasis>" msgstr "" +"El elemento <literal>properties</literal> define una configuración especifica de la implementación dada. La implementación basada en el sistema de archivos por ejemplo define el directorio raíz a utilizar, mientras que una implementación de la base de datos puede definir la URL de la base de datos, el nombre y la contraseña para establecer una conección a la base de datos. Esta configuración se pasa a la implementación CacheLoader por medio de <literal>CacheLoader.setConfig(Properties)</literal>. Observe que hay que escapar los retrocesos. <emphasis>Analogo al atributo " +"<literal>CacheLoaderConfig</literal> en configuraciones anteriores a 1.3.0.</" +"emphasis>" #. Tag: para #: Cache_loaders.xml:130 @@ -1148,6 +1196,8 @@ "<literal>ignoreModifications</literal> is <literal>false</literal>) when the " "cache loader starts up." msgstr "" +"<literal>purgeOnStatup</literal> vacía el cargador de caché especificado (si " +"<literal>ignoreModifications</literal> es <literal>false</literal>) cuando el cargador de caché inicie." #. Tag: title #: Cache_loaders.xml:151 @@ -1211,7 +1261,7 @@ #: Cache_loaders.xml:169 #, no-c-format msgid "Local cache with store" -msgstr "" +msgstr "Caché local con almacenamiento " #. Tag: para #: Cache_loaders.xml:170 @@ -1223,7 +1273,7 @@ "modifications back to the store. When the cache is started, depending on the " "<literal>preload</literal> element, certain data can be preloaded, so that " "the cache is partly warmed up." -msgstr "" +msgstr "Este es el caso más simple. Tenemos una instancia JBossCache, cuyo modo es <literal>LOCAL</literal> por lo tanto no hay replicaciones. El CacheLoader simplemente carga elementos no existentes del almacenamiento y almacena modificaciones de regreso en el almacenamiento. Cuando se incia el caché dependiendo del elemento <literal>preload</literal>, ciertos datos pueden ser precargados así que el caché en parte está precalentado." #. Tag: para #: Cache_loaders.xml:173

17 years

1
0
0 / 0

Hudson build completed: jboss-cache-core-2.1.X-jdk1.5 » JBoss Cache - Core Edition #56

by jboss-qa-internal＠redhat.com

See http://hudson.qa.jboss.com/hudson/job/jboss-cache-core-2.1.X-jdk1.5/org.j...

17 years

1
0
0 / 0

Build failed in Hudson: jboss-cache-core-2.1.X-jdk1.6 » JBoss Cache - Core Edition #51

by jboss-qa-internal＠redhat.com

See http://hudson.qa.jboss.com/hudson/job/jboss-cache-core-2.1.X-jdk1.6/org.j... ------------------------------------------ started Building remotely on dev17-rhel4-x86_64 $ java -Xmx512m -cp /home/hudson/hudson_workspace/maven-agent.jar:/qa/tools/opt/maven-2.0.9/boot/classworlds-1.1.jar hudson.maven.agent.Main /qa/tools/opt/maven-2.0.9 /qa/services/hudson/hudson_release/WEB-INF/slave.jar /home/hudson/hudson_workspace/maven-interceptor.jar channel started [INFO] Scanning for projects... WAGON_VERSION: 1.0-beta-2 [INFO] ------------------------------------------------------------------------ [INFO] Building JBoss Cache - Core Edition [INFO] task-segment: [clean, site] [INFO] ------------------------------------------------------------------------ [HUDSON] Archiving /home/hudson/hudson_workspace/workspace/jboss-cache-core-2.1.X-jdk1.6/./pom.xml [INFO] ------------------------------------------------------------------------ [ERROR] BUILD ERROR [INFO] ------------------------------------------------------------------------ [INFO] The plugin 'org.apache.maven.plugins:maven-eclipse-plugin' does not exist or no valid version could be found [INFO] ------------------------------------------------------------------------ [INFO] For more information, run Maven with the -e switch [INFO] ------------------------------------------------------------------------ [INFO] Total time: 28 seconds [INFO] Finished at: Sun Sep 21 10:16:58 EDT 2008 [INFO] Final Memory: 13M/50M [INFO] ------------------------------------------------------------------------ Waiting for Hudson to finish collecting data

17 years

1
4
0 / 0

JBoss Cache SVN: r6983 - core/trunk/src/main/java/org/jboss/cache.

by jbosscache-commits＠lists.jboss.org

Author: manik.surtani(a)jboss.com Date: 2008-10-19 05:47:09 -0400 (Sun, 19 Oct 2008) New Revision: 6983 Modified: core/trunk/src/main/java/org/jboss/cache/DefaultCacheFactory.java Log: Fixed rtn type Modified: core/trunk/src/main/java/org/jboss/cache/DefaultCacheFactory.java =================================================================== --- core/trunk/src/main/java/org/jboss/cache/DefaultCacheFactory.java 2008-10-18 13:50:21 UTC (rev 6982) +++ core/trunk/src/main/java/org/jboss/cache/DefaultCacheFactory.java 2008-10-19 09:47:09 UTC (rev 6983) @@ -56,7 +56,7 @@ @SuppressWarnings("unchecked") @Deprecated @Compat - public static DefaultCacheFactory getInstance() + public static CacheFactory getInstance() { return new DefaultCacheFactory(); }

17 years

1
0
0 / 0

JBoss Cache SVN: r6982 - in searchable/trunk: src/main/java/org/jboss/cache/search and 1 other directories.

by jbosscache-commits＠lists.jboss.org

Author: manik.surtani(a)jboss.com Date: 2008-10-18 09:50:21 -0400 (Sat, 18 Oct 2008) New Revision: 6982 Modified: searchable/trunk/pom.xml searchable/trunk/src/main/java/org/jboss/cache/search/SearchableCache.java searchable/trunk/src/main/java/org/jboss/cache/search/SearchableCacheImpl.java searchable/trunk/src/test/java/org/jboss/cache/search/blackbox/LocalPOJOCacheTest.java Log: Updated to JBC 3.0.0.CR1 Modified: searchable/trunk/pom.xml =================================================================== --- searchable/trunk/pom.xml 2008-10-17 18:11:32 UTC (rev 6981) +++ searchable/trunk/pom.xml 2008-10-18 13:50:21 UTC (rev 6982) @@ -25,7 +25,7 @@ <dependency> <groupId>org.jboss.cache</groupId> <artifactId>jbosscache-core</artifactId> - <version>2.2.0.GA</version> + <version>3.0.0.CR1</version> </dependency> <dependency> Modified: searchable/trunk/src/main/java/org/jboss/cache/search/SearchableCache.java =================================================================== --- searchable/trunk/src/main/java/org/jboss/cache/search/SearchableCache.java 2008-10-17 18:11:32 UTC (rev 6981) +++ searchable/trunk/src/main/java/org/jboss/cache/search/SearchableCache.java 2008-10-18 13:50:21 UTC (rev 6982) @@ -18,7 +18,7 @@ * License along with this software; if not, write to the Free * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA * 02110-1301 USA, or see the FSF site: http://www.fsf.org. - */ + */ package org.jboss.cache.search; @@ -26,10 +26,11 @@ import org.jboss.cache.Cache; /** - * This will be the most used interface in JBossCache searchable. It extends Cache and therefore will have - * the standard get(), put() and remove() methods. The additional method is the createQuery method which people - * will use to build their Hibernate Search queries from a luceneQuery - Hibernate Search users will be very familiar - * with this. + * This will be the most used interface in JBossCache searchable. It extends Cache and therefore will have + * the standard get(), put() and remove() methods. The additional method is the createQuery method which people + * will use to build their Hibernate Search queries from a luceneQuery - Hibernate Search users will be very familiar + * with this. + * * @author Navin Surtani (<a href="mailto:nsurtani@redhat.com">nsurtani(a)redhat.com</a>) * <p/> */ @@ -42,15 +43,14 @@ * @param luceneQuery - from {@link org.apache.lucene.search.Query} * @return a CacheQuery instance from which the user can get a list/iterator object. */ - public CacheQuery createQuery(Query luceneQuery); + CacheQuery createQuery(Query luceneQuery); /** * Creates a CacheQuery from a lucene query and a class array. * - * @param classes - array of classes to be searched from. + * @param classes - array of classes to be searched from. * @param luceneQuery - from {@link org.apache.lucene.search.Query} * @return a CacheQuery instance from which the user can get a list/iterator object. */ - public CacheQuery createQuery(Query luceneQuery, Class... classes); - + CacheQuery createQuery(Query luceneQuery, Class... classes); } Modified: searchable/trunk/src/main/java/org/jboss/cache/search/SearchableCacheImpl.java =================================================================== --- searchable/trunk/src/main/java/org/jboss/cache/search/SearchableCacheImpl.java 2008-10-17 18:11:32 UTC (rev 6981) +++ searchable/trunk/src/main/java/org/jboss/cache/search/SearchableCacheImpl.java 2008-10-18 13:50:21 UTC (rev 6982) @@ -18,7 +18,7 @@ * License along with this software; if not, write to the Free * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA * 02110-1301 USA, or see the FSF site: http://www.fsf.org. - */ + */ package org.jboss.cache.search; @@ -77,7 +77,7 @@ * Creates a CacheQuery object from a Lucene Query and a class array. * * @param luceneQuery - for lucene - * @param classes array + * @param classes array * @return CacheQuery object. */ @@ -115,8 +115,6 @@ * * @param listener */ - - //TODO: Does this have to be a CacheListener? public void addCacheListener(Object listener) { cache.addCacheListener(listener); @@ -127,8 +125,6 @@ * * @param listener */ - - public void removeCacheListener(Object listener) { cache.removeCacheListener(listener); @@ -145,7 +141,12 @@ return cache.getCacheListeners(); } + public V put(Fqn fqn, K key, V value) + { + return cache.put(fqn, key, value); + } + /** * Puts something into the cache with a given Fqn, key and value. * @@ -160,33 +161,36 @@ return cache.put(fqn, key, value); } - /** - * Puts something into the cache with a given Fqn and Map instance. - * - * @param fqn - * @param data - */ + public void putForExternalRead(Fqn fqn, K key, V value) + { + cache.put(fqn, key, value); + } + public void put(Fqn fqn, Map<? extends K, ? extends V> data) + { + cache.put(fqn, data); + } - public void put(String fqn, Map<K, V> data) + public void put(String fqn, Map<? extends K, ? extends V> data) { cache.put(fqn, data); } - /** - * Removes something from the cache with a given Fqn and key. - * - * @param fqn - * @param key - * @return - */ + public V remove(Fqn fqn, K key) + { + return cache.remove(fqn, key); + } - public V remove(String fqn, K key) { return cache.remove(fqn, key); } + public boolean removeNode(Fqn fqn) + { + return cache.removeNode(fqn); + } + /** * Convenience method that takes a string representation of an Fqn. Otherwise identical to removeNode(Fqn) * @@ -199,6 +203,11 @@ return cache.removeNode(fqn); } + public Node<K, V> getNode(Fqn fqn) + { + return cache.getNode(fqn); + } + /** * Gets a node from a String representation of a Fqn * @@ -211,6 +220,11 @@ return cache.getNode(fqn); } + public V get(Fqn fqn, K key) + { + return cache.get(fqn, key); + } + /** * Convenience method that allows for direct access to the data in a Node. * @@ -223,6 +237,26 @@ return cache.get(fqn, key); } + public void evict(Fqn fqn, boolean recursive) + { + cache.evict(fqn, recursive); + } + + public void evict(Fqn fqn) + { + cache.evict(fqn); + } + + public Region getRegion(Fqn fqn, boolean createIfAbsent) + { + return cache.getRegion(fqn, createIfAbsent); + } + + public boolean removeRegion(Fqn fqn) + { + return cache.removeRegion(fqn); + } + /** * Lifecycle method that initializes configuration state, the root node, etc. * @@ -268,6 +302,7 @@ /** * Gets where the cache currently is its lifecycle transitions. + * * @return the CacheStatus. Will not return null. */ @@ -278,7 +313,7 @@ /** * The current invocation context for the current invocation and cache instance. - * + * * @return the current invocation context for the current invocation and cache instance */ public InvocationContext getInvocationContext() @@ -299,7 +334,7 @@ /** * Returns the local address of this cache in a cluster, or null if running in local mode. - * + * * @return Returns the local address of this cache in a cluster, or null if running in local mode. */ public Address getLocalAddress() @@ -309,7 +344,7 @@ /** * Returns a list of members in the cluster, or null if running in local mode. - * + * * @return Returns a list of members in the cluster, or null if running in local mode. */ @@ -319,9 +354,14 @@ return cache.getMembers(); } + public void move(Fqn nodeToMove, Fqn newParent) throws NodeNotExistsException + { + cache.move(nodeToMove, newParent); + } + /** * Moves a part of the cache to a different subtree. Takes Strings for convenience. - * + * * @param nodeToMove * @param newParent * @throws NodeNotExistsException @@ -333,7 +373,7 @@ /** * Returns the version of the cache as a string. - * + * * @return Returns the version of the cache as a string. */ public String getVersion() @@ -341,6 +381,11 @@ return cache.getVersion(); } + public Map<K, V> getData(Fqn fqn) + { + return cache.getData(fqn); + } + /** * Returns a set of attribute keys for the Fqn. Takes Strings for convenience. * @@ -353,197 +398,28 @@ return cache.getKeys(fqn); } - /** - * Removes the keys and properties from a named node. Takes Strings for convenience. - * - * @param fqn - */ + public Set<K> getKeys(Fqn fqn) + { + return cache.getKeys(fqn); + } public void clearData(String fqn) { cache.clearData(fqn); } - /** - * Removes the keys and properties from a named node. - * @param fqn - */ - - public void clearData(Fqn<?> fqn) + public void clearData(Fqn fqn) { cache.clearData(fqn); } - /** - * Returns a set of attribute keys for the Fqn. - * - * @param fqn - * @return - */ - public Set getKeys(Fqn<?> fqn) + public void startBatch() { - return cache.getKeys(fqn); + cache.startBatch(); } - /** - * Retrieves a defensively copied data map of the underlying node. - * - * @param fqn - * @return a defensively copied data map of the underlying node. - */ - public Map getData(Fqn<?> fqn) + public void endBatch(boolean successful) { - return cache.getData(fqn); + cache.endBatch(successful); } - - /** - * Moves a part of the cache to a different subtree. - * - * @param nodeToMove - * @param newParent - * @throws NodeNotExistsException - */ - public void move(Fqn<?> nodeToMove, Fqn<?> newParent) throws NodeNotExistsException - { - cache.move(nodeToMove, newParent); - } - - /** - * Removes a region denoted by the Fqn passed in. - * - * @param fqn - * @return True if the region did exist and was removed, false otherwise. - */ - - public boolean removeRegion(Fqn<?> fqn) - { - return cache.removeRegion(fqn); - } - - /** - * Retrieves a Region for a given Fqn. - * - * @param fqn - * @param createIfAbsent - * @return a MarshRegion. Null if none is found. - */ - public Region getRegion(Fqn<?> fqn, boolean createIfAbsent) - { - return cache.getRegion(fqn, createIfAbsent); - } - - /** - * Eviction call that evicts the specified Node from memory. - * - * @param fqn - */ - - public void evict(Fqn<?> fqn) - { - cache.evict(fqn); - } - - /** - * Eviction call that evicts the specified Node from memory. - * - * @param fqn - * @param recursive - */ - - - public void evict(Fqn<?> fqn, boolean recursive) - { - cache.evict(fqn, recursive); - } - - /** - * Convenience method that allows for direct access to the data in a Node. - * - * @param fqn - * @param key - * @return - */ - - - public V get(Fqn<?> fqn, K key) - { - return cache.get(fqn, key); - } - - /** - * A convenience method to retrieve a node directly from the cache. - * - * @param fqn - * @return - */ - - public Node getNode(Fqn<?> fqn) - { - return cache.getNode(fqn); - } - - /** - * Removes a Node indicated by absolute Fqn. - * - * @param fqn - * @return True if the node was removed, false if the node was not found. - */ - public boolean removeNode(Fqn<?> fqn) - { - return cache.removeNode(fqn); - } - - /** - * Moves a part of the cache to a different subtree. - * - * @param fqn - * @param key - * @return - */ - public V remove(Fqn<?> fqn, K key) - { - return cache.remove(fqn, key); - } - - /** - * Copies all of the mappings from the specified map to a Node. - * - * @param fqn - * @param data - */ - - - public void put(Fqn<?> fqn, Map<K, V> data) - { - cache.put(fqn, data); - } - - /** - * Under special operating behavior, associates the value with the specified key for a node identified - * by the Fqn passed in. - * @param fqn - * @param key - * @param value - */ - - public void putForExternalRead(Fqn<?> fqn, K key, V value) - { - cache.putForExternalRead(fqn, key, value); - } - - /** - * Associates the specified value with the specified key for a Node in this cache. - * - * - * @param fqn - * @param key - * @param value - * @return - */ - - - public V put(Fqn<?> fqn, K key, V value) - { - return cache.put(fqn, key, value); - } } Modified: searchable/trunk/src/test/java/org/jboss/cache/search/blackbox/LocalPOJOCacheTest.java =================================================================== --- searchable/trunk/src/test/java/org/jboss/cache/search/blackbox/LocalPOJOCacheTest.java 2008-10-17 18:11:32 UTC (rev 6981) +++ searchable/trunk/src/test/java/org/jboss/cache/search/blackbox/LocalPOJOCacheTest.java 2008-10-18 13:50:21 UTC (rev 6982) @@ -1,11 +1,11 @@ package org.jboss.cache.search.blackbox; +import org.apache.commons.logging.Log; +import org.apache.commons.logging.LogFactory; import org.apache.lucene.analysis.standard.StandardAnalyzer; import org.apache.lucene.queryParser.ParseException; import org.apache.lucene.queryParser.QueryParser; import org.apache.lucene.search.Query; -import org.apache.commons.logging.Log; -import org.apache.commons.logging.LogFactory; import org.jboss.cache.Fqn; import org.jboss.cache.config.Configuration; import org.jboss.cache.pojo.PojoCache; @@ -29,7 +29,7 @@ * @author Navin Surtani (<a href="mailto:nsurtani@redhat.com">nsurtani(a)redhat.com</a>) */ -@Test(groups = "functional", enabled = true) +@Test(groups = "functional", enabled = false) public class LocalPOJOCacheTest { SearchableCache searchableCache; @@ -60,7 +60,7 @@ person2 = new Person(); person2.setName("BigGoat"); person2.setBlurb("Eats grass"); - + person3 = new Person(); person3.setName("MiniGoat"); person3.setBlurb("Eats cheese");

17 years

1
0
0 / 0

JBoss Cache SVN: r6981 - in core/trunk/src/main: docbook/userguide/en and 2 other directories.

by jbosscache-commits＠lists.jboss.org

Author: manik.surtani(a)jboss.com Date: 2008-10-17 14:11:32 -0400 (Fri, 17 Oct 2008) New Revision: 6981 Modified: core/trunk/src/main/docbook/faq/en/master.xml core/trunk/src/main/docbook/userguide/en/master.xml core/trunk/src/main/docbook/userguide/en/modules/architecture.xml core/trunk/src/main/docbook/userguide/en/modules/cache_loaders.xml core/trunk/src/main/docbook/userguide/en/modules/compatibility.xml core/trunk/src/main/docbook/userguide/en/modules/deployment.xml core/trunk/src/main/docbook/userguide/en/modules/introduction.xml core/trunk/src/main/docbook/userguide/en/modules/preface.xml core/trunk/src/main/docbook/userguide/en/modules/replication.xml core/trunk/src/main/docbook/userguide/en/modules/transactions.xml core/trunk/src/main/java/org/jboss/cache/Cache.java core/trunk/src/main/java/org/jboss/cache/CacheSPI.java Log: More documentation changes Modified: core/trunk/src/main/docbook/faq/en/master.xml =================================================================== --- core/trunk/src/main/docbook/faq/en/master.xml 2008-10-17 17:17:17 UTC (rev 6980) +++ core/trunk/src/main/docbook/faq/en/master.xml 2008-10-17 18:11:32 UTC (rev 6981) @@ -94,7 +94,7 @@ <literal>org.jboss.cache.pojo.PojoCache</literal> interface) is built atop the core library and allows introspection of objects in the cache providing transparent coherence by using JBoss AOP. Note that the POJO edition of JBoss Cache - (often referred to as POJO Cache) comes with a separate set of documentation (user guide, FAQ, etc.) + (often referred to as POJO Cache) comes with a separate set of documentation (Users' Guide, FAQ, etc.) available on the JBoss Cache <ulink url="http://www.jboss.org/jbosscache/">documentation website</ulink>. </para> @@ -216,7 +216,7 @@ <para> Absolutely! Even though JBoss Cache comes integrated with JBoss Application Server, it can also be used in any other Java EE server such as BEA WebLogic, IBM Websphere or Tomcat. It - can also run in a standalone Java process, completely outside of an application server. See the user guide for more + can also run in a standalone Java process, completely outside of an application server. See the Users' Guide for more details. </para> </answer> @@ -438,7 +438,7 @@ every replication change is propagated to all participating members. There is no mechanism for sub-partitioning where some replication can be done within only a subset of members, unless you use the Buddy Replication features. See the - user guide for more details on this. + Users' Guide for more details on this. </para> </answer> </qandaentry> @@ -489,7 +489,7 @@ very easily with no extra impact on memory or network traffic with each node added. </para> <para> - See the User Guide for more information on Buddy Replication, and how it can be used to achieve very + See the Users' Guide for more information on Buddy Replication, and how it can be used to achieve very high scalability. </para> @@ -536,7 +536,7 @@ <para> Yes, it can be. For such cases it is recommended that you configure your cache using the JGroups Multiplexer, which allows several caches to share - a single JGroups channel. Please see the User Guide for details on how to configure the JGroups + a single JGroups channel. Please see the Users' Guide for details on how to configure the JGroups Multiplexer. </para> <para> @@ -752,7 +752,7 @@ <answer> <para> - Please see the configuration section of the user guide for details. + Please see the configuration section of the Users' Guide for details. </para> </answer> </qandaentry> @@ -816,7 +816,7 @@ <literal>jconsole</literal> utility. See the chapter titled <emphasis role="bold">Management Information</emphasis> - in the JBoss Cache user guide for more details. + in the JBoss Cache Users' Guide for more details. </para> </answer> </qandaentry> @@ -827,7 +827,7 @@ </question> <answer> - <para>Yes, you can. See the section on configuration in the JBoss Cache user guide. + <para>Yes, you can. See the section on configuration in the JBoss Cache Users' Guide. </para> </answer> </qandaentry> @@ -912,7 +912,7 @@ replicated to that portion. See the <literal>CacheMarshaller</literal> section of - the user guide for more details. + the Users' Guide for more details. </para> <para>To solve the second kind of issue, you can use the the <literal>UseLazyDeserialization</literal> configuration @@ -948,7 +948,7 @@ <answer> <para> - See the user guide on this subject. + See the Users' Guide on this subject. </para> </answer> </qandaentry> @@ -988,7 +988,7 @@ </para> <para>To implement this feature, please follow the instructions indicated in the example located - in the CacheMarshaller section of the user's guide. It's worth noting that instead of a + in the CacheMarshaller section of the Users' Guide. It's worth noting that instead of a <literal>ServletContextListener</literal> , you could add this code into an <literal>MBean</literal> @@ -1191,7 +1191,7 @@ </listitem> <listitem> - <para>And more. See the chapter on cache loaders in the User Guide for more details.</para> + <para>And more. See the chapter on cache loaders in the Users' Guide for more details.</para> </listitem> </itemizedlist> </para> @@ -1205,7 +1205,7 @@ <answer> <para> - No, it is not. The FileCacheLoader has some severe limitations which restrict it's use in a production + No, it is not. The FileCacheLoader has some severe limitations which restrict its use in a production environment, or if used in such an environment, it should be used with due care and sufficient understanding of these limitations. <itemizedlist> @@ -1225,7 +1225,7 @@ </itemizedlist> As a rule of thumb, it is recommended that the FileCacheLoader not be used in a highly concurrent, - transactional or stressful environment, and it's use is restricted to testing. + transactional or stressful environment, and its use is restricted to testing. </para> </answer> </qandaentry> @@ -1238,7 +1238,7 @@ <answer> <para>Yes. Set the <literal>async</literal> - attrobute to true. See the JBoss Cache User Guide for a more + attrobute to true. See the JBoss Cache Users' Guide for a more detailed discussion. By default though, all cache loader writes are synchronous and will block. </para> @@ -1256,7 +1256,7 @@ or extending <literal>org.jboss.cache.loader.AbstractCacheLoader</literal> . It is - configured via the XML file (see JBoss Cache User Guide). + configured via the XML file (see JBoss Cache Users' Guide). </para> </answer> </qandaentry> @@ -1334,7 +1334,7 @@ <answer> <para>Yes. Within the CacheLoaderConfiguration XML - element (see user guide chapter on cache loaders) you can + element (see Users' Guide chapter on cache loaders) you can describe several cache loaders. The impact is that the cache will look at all of the cache loaders in the order they've been configured, until it finds a valid, non-null element of data. When @@ -1354,7 +1354,7 @@ <answer> <para>Yes. See "Transforming Cache Loaders" section within the "Cache Loaders" section located in the - JBoss Cache users guide. + JBoss Cache Users' Guide. </para> </answer> </qandaentry> @@ -1368,7 +1368,7 @@ <answer> <para> - As of JBoss Cache 2.1.0, the answer is yes. See the User Guide for details on how to configure and + As of JBoss Cache 2.1.0, the answer is yes. See the Users' Guide for details on how to configure and tune your retries and wait period for reestablishing the TCP connection. </para> Modified: core/trunk/src/main/docbook/userguide/en/master.xml =================================================================== --- core/trunk/src/main/docbook/userguide/en/master.xml 2008-10-17 17:17:17 UTC (rev 6980) +++ core/trunk/src/main/docbook/userguide/en/master.xml 2008-10-17 18:11:32 UTC (rev 6981) @@ -18,7 +18,7 @@ ]> <book lang="en"> <bookinfo> - <title>JBoss Cache User Guide</title> + <title>JBoss Cache Users' Guide</title> <subtitle>A clustered, transactional cache</subtitle>  @@ -78,8 +78,8 @@ &introduction; &basic_api; &configuration; + &batching; &deployment; - &batching; &compatibility; </part> Modified: core/trunk/src/main/docbook/userguide/en/modules/architecture.xml =================================================================== --- core/trunk/src/main/docbook/userguide/en/modules/architecture.xml 2008-10-17 17:17:17 UTC (rev 6980) +++ core/trunk/src/main/docbook/userguide/en/modules/architecture.xml 2008-10-17 18:11:32 UTC (rev 6981) @@ -3,33 +3,16 @@ <section id="architecture.tree_structure"> <title>Data Structures Within The Cache</title> - <para> - A - <literal>Cache</literal> - consists of a collection of - <literal>Node</literal> - instances, organised in a tree - structure. Each - <literal>Node</literal> - contains a - <literal>Map</literal> - which holds the data + A <literal>Cache</literal> consists of a collection of <literal>Node</literal> instances, organised in a tree + structure. Each <literal>Node</literal> contains a <literal>Map</literal> which holds the data objects to be cached. It is important to note that the structure is a mathematical tree, and not a graph; each - <literal>Node</literal> - has one and only one parent, and the root node is denoted by the constant fully qualitied name, - <literal>Fqn.ROOT</literal> - . + <literal>Node</literal> has one and only one parent, and the root node is denoted by the constant fully qualified + name, <literal>Fqn.ROOT</literal>. </para> <para> - The reason for organising nodes as such is to improve concurrent access to data and make replication and - persistence - more fine-grained. - </para> - <para> <figure> <title>Data structured as a tree</title> - <mediaobject> <imageobject> <imagedata fileref="TreeCacheArchitecture.png"/> @@ -39,16 +22,10 @@ In the diagram above, each box represents a JVM. You see 2 caches in separate JVMs, replicating data to each other. - These VMs can be located on the same physical machine, or on 2 different machines connected by a network link. - The - underlying group communication between networked nodes is done using - <ulink url="http://www.jgroups.org">JGroups</ulink> - . </para> - <para>Any modifications (see - <link linkend="api">API chapter</link> - ) in one cache instance will be replicated to + <para> + Any modifications (see <link linkend="api">API chapter</link>) in one cache instance will be replicated to the other cache. Naturally, you can have more than 2 caches in a cluster. Depending on the transactional settings, this replication will occur either after each modification or at the end of a transaction, at commit time. When a new cache is created, it can optionally acquire the contents @@ -59,21 +36,11 @@ <section id="architecture.SPI_interfaces"> <title>SPI Interfaces</title> <para> - In addition to - <literal>Cache</literal> - and - <literal>Node</literal> - interfaces, JBoss Cache exposes more powerful - <literal>CacheSPI</literal> - and - <literal>NodeSPI</literal> - interfaces, which offer more control over the internals - of JBoss Cache. These interfaces are not intended for general use, but are designed for people who wish to - extend and enhance JBoss Cache, or write custom - <literal>Interceptor</literal> - or - <literal>CacheLoader</literal> - instances. + In addition to <literal>Cache</literal> and <literal>Node</literal> interfaces, JBoss Cache exposes more + powerful <literal>CacheSPI</literal> and <literal>NodeSPI</literal> interfaces, which offer more control over + the internals of JBoss Cache. These interfaces are not intended for general use, but are designed for people + who wish to extend and enhance JBoss Cache, or write custom <literal>Interceptor</literal> or + <literal>CacheLoader</literal> instances. </para> <figure> <title>SPI Interfaces</title> @@ -85,41 +52,21 @@ </mediaobject> </figure> <para> - The - <literal>CacheSPI</literal> - interface cannot be created, but is injected into - <literal>Interceptor</literal> - and - <literal>CacheLoader</literal> - implementations by the - <literal>setCache(CacheSPI cache)</literal> - methods on these interfaces. - <literal>CacheSPI</literal> - extends - <literal>Cache</literal> - so all the functionality of the basic API is made available. + The <literal>CacheSPI</literal> interface cannot be created, but is injected into <literal>Interceptor</literal> + and <literal>CacheLoader</literal> implementations by the <literal>setCache(CacheSPI cache)</literal> + methods on these interfaces. <literal>CacheSPI</literal> extends <literal>Cache</literal> + so all the functionality of the basic API is also available. </para> <para> - Similarly, a - <literal>NodeSPI</literal> - interface cannot be created. Instead, one is obtained by performing operations on - <literal>CacheSPI</literal> - , - obtained as above. For example, - <literal>Cache.getRoot() : Node</literal> - is overridden as - <literal>CacheSPI.getRoot() : NodeSPI</literal> - . + Similarly, a <literal>NodeSPI</literal> interface cannot be created. Instead, one is obtained by performing + operations on <literal>CacheSPI</literal>, obtained as above. For example, <literal>Cache.getRoot() : Node</literal> + is overridden as <literal>CacheSPI.getRoot() : NodeSPI</literal>. </para> <para> - It is important to note that directly casting a - <literal>Cache</literal> - or - <literal>Node</literal> - to it's SPI - counterpart is not recommended and is bad practice, since the inheritace of interfaces it is not a contract - that is guaranteed to be upheld moving forward. The exposed public APIs, on the other hand, is guaranteed to - be upheld. + It is important to note that directly casting a <literal>Cache</literal> or <literal>Node</literal> + to its SPI counterpart is not recommended and is bad practice, since the inheritace of interfaces it is not a + contract that is guaranteed to be upheld moving forward. The exposed public APIs, on the other hand, is + guaranteed to be upheld. </para> </section> @@ -133,42 +80,33 @@ when the cache is created, based on the configuration used. </para> <para> - It is important to note that the - <literal>NodeSPI</literal> - offers some methods (such as the - <literal>xxxDirect()</literal> - method - family) that operate on a node directly without passing through the interceptor stack. Plugin authors should - note - that using such methods will affect the aspects of the cache that may need to be applied, such as locking, - replication, etc. Basically, don't use such methods unless you - <emphasis>really</emphasis> + It is important to note that the <literal>NodeSPI</literal> offers some methods (such as the <literal>xxxDirect()</literal> + method family) that operate on a node directly without passing through the interceptor stack. Plugin authors + should note that using such methods will affect the aspects of the cache that may need to be applied, such as + locking, replication, etc. To put it simply, don't use such methods unless you <emphasis>really</emphasis> know what you're doing! </para> - <section id="architecture.interceptors"> + + <section id="architecture.interceptors"> <title>Interceptors</title> <para> - An - <literal>Interceptor</literal> - is an abstract class, several of which comprise an interceptor chain. It - exposes an - <literal>invoke()</literal> - method, which must be overridden by implementing classes to add behaviour - to a call before passing the call down the chain by calling - <literal>super.invoke()</literal> - . + JBoss Cache essentially is a core data structure - an implementation of <literal>DataContainer</literal> - and + aspects and features are implemented using interceptors in front of this data structure. A + <literal>CommandInterceptor</literal> is an abstract class, interceptor implementations extend this. </para> - <figure> - <title>SPI Interfaces</title> - - <mediaobject> - <imageobject> - <imagedata fileref="Interceptor.png"/> - </imageobject> - </mediaobject> - </figure> <para> - JBoss Cache ships with several interceptors, representing different configuration options, some of which + <literal>CommandInterceptor</literal> implements the <literal>Visitor</literal> interface so it is able to + alter commands in a strongly typed manner as the command makes its way to the data structure. More on + visitors and commands in the next section. + </para> + <para> + Interceptor implementations are chained together in the <literal>InterceptorChain</literal> class, which + dispatches a command across the chain of interceptors. A special interceptor, the <literal>CallInterceptor</literal>, + always sits at the end of this chain to invoke the command being passed up the chain by calling the + command's <literal>process()</literal> method. + </para> + <para> + JBoss Cache ships with several interceptors, representing different behavioral aspects, some of which are: <itemizedlist> <listitem> @@ -178,7 +116,7 @@ </listitem> <listitem> <literal>ReplicationInterceptor</literal> - - replicates state across a cluster using a JGroups channel + - replicates state across a cluster using the RpcManager class </listitem> <listitem> <literal>CacheLoaderInterceptor</literal> @@ -186,51 +124,53 @@ </listitem> </itemizedlist> The interceptor chain configured for your cache instance can be obtained and inspected by calling - <literal>CacheSPI.getInterceptorChain()</literal> - , - which returns an ordered - <literal>List</literal> - of interceptors. + <literal>CacheSPI.getInterceptorChain()</literal>, which returns an ordered <literal>List</literal> + of interceptors in the order in which they would be encountered by a command. </para> <section id="architecture.custom_interceptors"> <title>Writing Custom Interceptors</title> <para> Custom interceptors to add specific aspects or features can be written by extending - <literal>Interceptor</literal> - and overriding - <literal>invoke()</literal> - . The custom interceptor will need to be added to the interceptor chain by using the - <literal>CacheSPI.addInterceptor()</literal> - method. + <literal>CommandInterceptor</literal> and overriding the relevant + <literal>visitXXX()</literal> methods based on the commands you are interested in intercepting. There + are other abstract interceptors you could extend instead, such as the <literal>PrePostProcessingCommandInterceptor</literal> + and the <literal>SkipCheckChainedInterceptor</literal>. Please see their respective javadocs for details + on the extra features provided. </para> <para> - Adding custom interceptors via XML is not supported at this time. + The custom interceptor will need to be added to the interceptor chain by using the + <literal>Cache.addInterceptor()</literal> methods. See the javadocs on these methods for details. </para> + <para> + Adding custom interceptors via XML is also supported, please see the + <link linkend="configuration_reference_chapter">XML configuration reference</link> for details. + </para> </section> </section> - <section id="architecture.methodcalls"> - <title>MethodCalls</title> - <para> - <literal>org.jboss.cache.marshall.MethodCall</literal> - is a class that encapsulates a - <literal>java.lang.reflection.Method</literal> - and an - <literal>Object[]</literal> - representing the method's arguments. It is an extension of the - <literal>org.jgroups.blocks.MethodCall</literal> - class, that adds a mechanism for identifying known methods using magic numbers and method ids, - which makes marshalling and unmarshalling more efficient and performant. - </para> - <para> - This is central to the - <literal>Interceptor</literal> - architecture, and is the only parameter passed in to - <literal>Interceptor.invoke()</literal> - . - </para> - </section> - + <section id="architecture.commands"> + <title>Commands and Visitors</title> + <para> + Internally, JBoss Cache uses a command/visitor pattern to execute API calls. Whenever a method is called + on the cache interface, the <literal>CacheInvocationDelegate</literal>, which implements the <literal>Cache</literal> + interface, creates an instance of <literal>VisitableCommand</literal> and dispatches this command up a chain of + interceptors. Interceptors, which implement the <literal>Visitor</literal> interface, are able to handle + <literal>VisitableCommand</literal>s they are interested in, and add behavior to the command. + </para> + <para> + Each command contains all knowledge of the command being executed such as parameters used and processing + behavior, encapsulated in a <literal>process()</literal> method. For example, the <literal>RemoveNodeCommand</literal> + is created and passed up the interceptor chain when <literal>Cache.removeNode()</literal> is called, and + <literal>RemoveNodeCommand.process()</literal> has the necessary knowledge of how to remove a node from + the data structure. + </para> + <para> + In addition to being visitable, commands are also replicable. The JBoss Cache marshallers know how to + efficiently marshall commands and invoke them on remote cache instances using an internal RPC mechanism + based on JGroups. + </para> + </section> + <section id="architecture.invocationcontext"> <title>InvocationContexts</title> <para> @@ -238,7 +178,7 @@ holds intermediate state for the duration of a single invocation, and is set up and destroyed by the <literal>InvocationContextInterceptor</literal> - which sits at the start of the chain. + which sits at the start of the interceptor chain. </para> <para> <literal>InvocationContext</literal> @@ -255,15 +195,13 @@ linkend="configuration.options"> <literal>Option</literal> overrides - </link> - . + </link>, and information around which nodes have been locked, etc. </para> <para> The <literal>InvocationContext</literal> can be obtained by calling - <literal>Cache.getInvocationContext()</literal> - . + <literal>Cache.getInvocationContext()</literal>. </para> </section> </section> @@ -346,21 +284,17 @@ <literal>VersionAwareMarshaller</literal> and a concrete - <literal>CacheMarshaller200</literal> + <literal>CacheMarshaller300</literal> . </para> <para> The marshaller can be obtained by calling - <literal>CacheSPI.getMarshaller()</literal> - , and defaults to the - <literal>VersionAwareMarshaller</literal> - . + <literal>CacheSPI.getMarshaller()</literal>, and defaults to the + <literal>VersionAwareMarshaller</literal>. Users may also write their own marshallers by implementing the <literal>Marshaller</literal> - interface and - adding it to their configuration, by using the - <literal>MarshallerClass</literal> - configuration attribute. + interface or extending the <literal>AbstractMarshaller</literal> class, and adding it to their configuration + by using the <literal>Configuration.setMarshallerClass()</literal> setter. </para> </section> @@ -376,86 +310,16 @@ know which specific marshaller implementation to delegate the call to. For example, <literal>CacheMarshaller200</literal> - , is the marshaller for JBoss Cache 2.0.x. - JBoss Cache 2.1.x, say, may ship with - <literal>CacheMarshaller210</literal> - with an improved wire protocol. - Using a + is the marshaller for JBoss Cache 2.0.x. + JBoss Cache 3.0.x ships with + <literal>CacheMarshaller300</literal> + with an improved wire protocol. Using a <literal>VersionAwareMarshaller</literal> helps achieve wire protocol compatibility between minor releases but still affords us the flexibility to tweak and improve the wire protocol between minor or micro releases. </para> - - <section> - <title>CacheLoaders</title> - <para> - Some of the existing cache loaders, such as the - <literal>JDBCCacheLoader</literal> - and the - <literal>FileCacheLoader</literal> - relied on persisting data using - <literal>ObjectOutputStream</literal> - as well, but now, they are using the - <literal>VersionAwareMarshaller</literal> - to marshall the persisted - data to their cache stores. - </para> - </section> - </section> - - <section> - <title>CacheMarshaller200</title> - <para> - This marshaller treats well-known objects that need marshalling - such as - <literal>MethodCall</literal> - , - <literal>Fqn</literal> - , - <literal>DataVersion</literal> - , and even some JDK objects such as - <literal>String</literal> - , - <literal>List</literal> - , - <literal>Boolean</literal> - and others as types that do not need complete class definitions. - Instead, each of these well-known types are represented by a - <literal>short</literal> - , which is a lot more efficient. - </para> - <para> - In addition, reference counting is done to reduce duplication of writing certain objects multiple times, to - help - keep the streams small and efficient. - </para> - <para> - Also, if - <literal>UseRegionBasedMarshalling</literal> - is enabled (disabled by default) the marshaller adds region - information to the stream before writing any data. This region information is in the form of a - <literal>String</literal> - representation of an - <literal>Fqn</literal> - . When unmarshalling, the - <literal>RegionManager</literal> - can be used to - find the relevant - <literal>Region</literal> - , and use a region-specific - <literal>ClassLoader</literal> - to unmarshall - the stream. This is specifically useful when used to cluster state for application servers, where each - deployment has - it's own - <literal>ClassLoader</literal> - . See the section below on - <link linkend="architecture.regions">regions</link> - for more information. - </para> - </section> - </section> <section id="architecture.regions"> <title>Class Loading and Regions</title> @@ -468,15 +332,12 @@ would require replication. It is common for application servers to assign separate <literal>ClassLoader</literal> instances to each application deployed, but have JBoss Cache libraries referenced by the application server's - <literal>ClassLoader</literal> - . + <literal>ClassLoader</literal>. </para> <para> To enable us to successfully marshall and unmarshall objects from such class loaders, we use a concept called regions. A region is a portion of the cache which share a common class loader (a region also has other uses - - see - <link linkend="eviction_policies">eviction policies</link> - ). + see <link linkend="eviction_policies">eviction policies</link>). </para> <para> A region is created by using the @@ -490,9 +351,7 @@ are active unless the <literal>InactiveOnStartup</literal> configuration attribute is set to - <literal>true</literal> - . + <literal>true</literal>. </para> </section> - </chapter> Modified: core/trunk/src/main/docbook/userguide/en/modules/cache_loaders.xml =================================================================== --- core/trunk/src/main/docbook/userguide/en/modules/cache_loaders.xml 2008-10-17 17:17:17 UTC (rev 6980) +++ core/trunk/src/main/docbook/userguide/en/modules/cache_loaders.xml 2008-10-17 18:11:32 UTC (rev 6981) @@ -151,22 +151,15 @@ ...  -<attribute name="CacheLoaderConfiguration"> - <config> + +<loaders passivation="false" shared="false"> + <preload> +  + <node fqn="/some/stuff"/> + </preload>  - <passivation>false</passivation> -  - <preload>/</preload> -  - <shared>false</shared> - -  -  - <cacheloader> - - <class>org.jboss.cache.loader.JDBCCacheLoader</class> - -  + <loader class="org.jboss.cache.loader.JDBCCacheLoader" async="false" fetchPersistentState="true" + ignoreModifications="false" purgeOnStartup="false"> <properties> cache.jdbc.driver=com.mysql.jdbc.Driver cache.jdbc.url=jdbc:mysql://localhost:3306/jbossdb @@ -174,43 +167,8 @@ cache.jdbc.password= cache.jdbc.sql-concat=concat(1,2) </properties> - -  - <async>false</async> - -  - <fetchPersistentState>true</fetchPersistentState> - -  - <ignoreModifications>false</ignoreModifications> - -  - <purgeOnStartup>false</purgeOnStartup> - -  - <singletonStore> -  - <enabled>false</enabled> - -  - <class>org.jboss.cache.loader.SingletonStoreCacheLoader</class> - -  - <properties> - pushStateWhenCoordinator=true - pushStateWhenCoordinatorTimeout=20000 - </properties> - </singletonStore> - </cacheloader> - - </config> -</attribute> + </loader> + </loaders> ]]></programlisting> <para>The @@ -344,6 +302,28 @@ <section> <title>Singleton Store Configuration</title> + <programlisting role="XML"><![CDATA[ + <loaders passivation="false" shared="true"> + <preload> + <node fqn="/a/b/c"/> + <node fqn="/f/r/s"/> + </preload> + +  + <loader class="org.jboss.cache.loader.JDBCCacheLoader" async="false" fetchPersistentState="false" + ignoreModifications="false" purgeOnStartup="false"> + <properties> + cache.jdbc.datasource=java:/DefaultDS + </properties> + <singletonStore enabled="true" class="org.jboss.cache.loader.SingletonStoreCacheLoader"> + <properties> + pushStateWhenCoordinator=true + pushStateWhenCoordinatorTimeout=20000 + </properties> + </singletonStore> + </loader> + </loaders> + ]]></programlisting> <para> <literal>singletonStore</literal> element enables modifications to be stored by only one node in the cluster, @@ -355,7 +335,7 @@ subelement to true in all nodes, but again only the coordinator of the cluster will store the modifications in the underlying cache loader as defined in - <literal>cacheloader</literal> + <literal>loader</literal> element. You cannot define a cache loader as <literal>shared</literal> and with @@ -446,6 +426,7 @@ coordinator crashes or stops responding. </para> </section> + </section> <section id="cl.impls"> @@ -459,7 +440,7 @@ <para> JBoss Cache ships with several cache loaders that utilise the file system as a data store. They all require that the - <literal><![CDATA[<cacheloader><properties>]]></literal> + <literal><![CDATA[<loader><properties>]]></literal> configuration element contains a <literal>location</literal> @@ -486,7 +467,7 @@ ). </para> <para> - The FileCacheLoader has some severe limitations which restrict it's use in a production + The FileCacheLoader has some severe limitations which restrict its use in a production environment, or if used in such an environment, it should be used with due care and sufficient understanding of these limitations. <itemizedlist> @@ -506,7 +487,7 @@ </itemizedlist> As a rule of thumb, it is recommended that the FileCacheLoader not be used in a highly concurrent, - transactional or stressful environment, and it's use is restricted to testing. + transactional or stressful environment, and its use is restricted to testing. </para> </listitem> @@ -602,8 +583,7 @@ </para> <para> - <literal>Fqn</literal> - 's are stored as strings. Node content is stored + <literal>Fqn</literal>s are stored as strings. Node content is stored as a BLOB. <emphasis>WARNING:</emphasis> JBoss Cache does not impose any @@ -626,10 +606,7 @@ </para> <para>See - <ulink - url="http://wiki.jboss.org/wiki/Wiki.jsp?page=JDBCCacheLoader"> - http://wiki.jboss.org/wiki/Wiki.jsp?page=JDBCCacheLoader - </ulink> + <ulink url="http://www.jboss.org/community/docs/DOC-10864">this wiki page</ulink> for configuration tips with specific database systems. </para> @@ -646,7 +623,7 @@ <emphasis>cache.jdbc.table.name</emphasis> - the name of the table. Can be prepended with schema name for the given table: - <schema_name>.<table_name>. + <literal>{schema_name}.{table_name}</literal>. The default value is 'jbosscache'. </listitem> @@ -798,37 +775,31 @@ </para> <programlisting role="XML"><![CDATA[ -<attribute name="CacheLoaderConfiguration"> -<config> - <passivation>false</passivation> - <preload>/some/stuff</preload> - <cacheloader> - <class>org.jboss.cache.loader.JDBCCacheLoader</class> - - <properties> - cache.jdbc.table.name=jbosscache - cache.jdbc.table.create=true - cache.jdbc.table.drop=true - cache.jdbc.table.primarykey=jbosscache_pk - cache.jdbc.fqn.column=fqn - cache.jdbc.fqn.type=varchar(255) - cache.jdbc.node.column=node - cache.jdbc.node.type=blob - cache.jdbc.parent.column=parent - cache.jdbc.driver=oracle.jdbc.OracleDriver - cache.jdbc.url=jdbc:oracle:thin:@localhost:1521:JBOSSDB - cache.jdbc.user=SCOTT - cache.jdbc.password=TIGER - cache.jdbc.sql-concat=concat(1,2) - </properties> - - <async>false</async> - <fetchPersistentState>true</fetchPersistentState> - <ignoreModifications>false</ignoreModifications> - <purgeOnStartup>false</purgeOnStartup> - </cacheloader> -</config> -</attribute> +<loaders passivation="false" shared="false"> + <preload> + <node fqn="/some/stuff"/> + </preload> +  + <loader class="org.jboss.cache.loader.JDBCCacheLoader" async="false" fetchPersistentState="true" + ignoreModifications="false" purgeOnStartup="false"> + <properties> + cache.jdbc.table.name=jbosscache + cache.jdbc.table.create=true + cache.jdbc.table.drop=true + cache.jdbc.table.primarykey=jbosscache_pk + cache.jdbc.fqn.column=fqn + cache.jdbc.fqn.type=varchar(255) + cache.jdbc.node.column=node + cache.jdbc.node.type=blob + cache.jdbc.parent.column=parent + cache.jdbc.driver=oracle.jdbc.OracleDriver + cache.jdbc.url=jdbc:oracle:thin:@localhost:1521:JBOSSDB + cache.jdbc.user=SCOTT + cache.jdbc.password=TIGER + cache.jdbc.sql-concat=concat(1,2) + </properties> + </loader> + </loaders> ]]></programlisting> <para>As an alternative to configuring the entire JDBC connection, @@ -836,63 +807,51 @@ </para> <programlisting role="XML"><![CDATA[ -<attribute name="CacheLoaderConfiguration"> -<config> - <passivation>false</passivation> - <preload>/some/stuff</preload> - <cacheloader> - <class>org.jboss.cache.loader.JDBCCacheLoader</class> - - <properties> - cache.jdbc.datasource=java:/DefaultDS - </properties> - - <async>false</async> - <fetchPersistentState>true</fetchPersistentState> - <ignoreModifications>false</ignoreModifications> - <purgeOnStartup>false</purgeOnStartup> - </cacheloader> -</config> -</attribute> + <loaders passivation="false" shared="false"> + <preload> + <node fqn="/some/stuff"/> + </preload> +  + <loader class="org.jboss.cache.loader.JDBCCacheLoader" async="false" fetchPersistentState="true" + ignoreModifications="false" purgeOnStartup="false"> + <properties> + cache.jdbc.datasource=java:/DefaultDS + </properties> + </loader> + </loaders> ]]></programlisting> <para>Cconfiguration example for a cache loader using c3p0 JDBC connection pooling:</para> <programlisting role="XML"><![CDATA[ -<attribute name="CacheLoaderConfiguration"> -<config> - <passivation>false</passivation> - <preload>/some/stuff</preload> - <cacheloader> - <class>org.jboss.cache.loader.JDBCCacheLoader</class> - - <properties> - cache.jdbc.table.name=jbosscache - cache.jdbc.table.create=true - cache.jdbc.table.drop=true - cache.jdbc.table.primarykey=jbosscache_pk - cache.jdbc.fqn.column=fqn - cache.jdbc.fqn.type=varchar(255) - cache.jdbc.node.column=node - cache.jdbc.node.type=blob - cache.jdbc.parent.column=parent - cache.jdbc.driver=oracle.jdbc.OracleDriver - cache.jdbc.url=jdbc:oracle:thin:@localhost:1521:JBOSSDB - cache.jdbc.user=SCOTT - cache.jdbc.password=TIGER - cache.jdbc.sql-concat=concat(1,2) - cache.jdbc.connection.factory=org.jboss.cache.loader.C3p0ConnectionFactory - c3p0.maxPoolSize=20 - c3p0.checkoutTimeout=5000 - </properties> - - <async>false</async> - <fetchPersistentState>true</fetchPersistentState> - <ignoreModifications>false</ignoreModifications> - <purgeOnStartup>false</purgeOnStartup> - </cacheloader> -</config> -</attribute> + <loaders passivation="false" shared="false"> + <preload> + <node fqn="/some/stuff"/> + </preload> +  + <loader class="org.jboss.cache.loader.JDBCCacheLoader" async="false" fetchPersistentState="true" + ignoreModifications="false" purgeOnStartup="false"> + <properties> + cache.jdbc.table.name=jbosscache + cache.jdbc.table.create=true + cache.jdbc.table.drop=true + cache.jdbc.table.primarykey=jbosscache_pk + cache.jdbc.fqn.column=fqn + cache.jdbc.fqn.type=varchar(255) + cache.jdbc.node.column=node + cache.jdbc.node.type=blob + cache.jdbc.parent.column=parent + cache.jdbc.driver=oracle.jdbc.OracleDriver + cache.jdbc.url=jdbc:oracle:thin:@localhost:1521:JBOSSDB + cache.jdbc.user=SCOTT + cache.jdbc.password=TIGER + cache.jdbc.sql-concat=concat(1,2) + cache.jdbc.connection.factory=org.jboss.cache.loader.C3p0ConnectionFactory + c3p0.maxPoolSize=20 + c3p0.checkoutTimeout=5000 + </properties> + </loader> + </loaders> ]]></programlisting> </section> @@ -1110,7 +1069,7 @@ </para> <para> - As of JBoss Cache 2.1.0, the TcpDelegatingCacheLoader transparently handles reconnects if the connection + As of JBoss Cache 2.1.0, the <literal>TcpDelegatingCacheLoader</literal> transparently handles reconnects if the connection to the TcpCacheServer is lost. </para> @@ -1132,19 +1091,20 @@ <para>The configuration looks as follows:</para> <programlisting role="XML"><![CDATA[ -<attribute name="CacheLoaderConfiguration"> -<config> - <cacheloader> - <class>org.jboss.cache.loader.TcpDelegatingCacheLoader</class> - <properties> - host=myRemoteServer - port=7500 - timeout=10000 - reconnectWaitTime=250 - </properties> - </cacheloader> -</config> -</attribute> + <loaders passivation="false" shared="false"> + <preload> + <node fqn="/"/> + </preload> +  + <loader class="org.jboss.cache.loader.TcpDelegatingCacheLoader"> + <properties> + host=myRemoteServer + port=7500 + timeout=10000 + reconnectWaitTime=250 + </properties> + </loader> + </loaders> ]]></programlisting> <para>This means this instance of JBoss Cache will delegate all load @@ -1298,22 +1258,22 @@ <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 + 1) Memory: /A Disk: /A + 2) Memory: /A, /B Disk: /A, /B + 3) Memory: /B Disk: /A, /B + 4) Memory: /A, /B Disk: /A, /B + 5) Memory: /A Disk: /A, /B + 6) Memory: /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: + 1) Memory: /A Disk: + 2) Memory: /A, /B Disk: + 3) Memory: /B Disk: /A + 4) Memory: /A, /B Disk: + 5) Memory: /A Disk: /B + 6) Memory: /A Disk: </programlisting> </section> Modified: core/trunk/src/main/docbook/userguide/en/modules/compatibility.xml =================================================================== --- core/trunk/src/main/docbook/userguide/en/modules/compatibility.xml 2008-10-17 17:17:17 UTC (rev 6980) +++ core/trunk/src/main/docbook/userguide/en/modules/compatibility.xml 2008-10-17 18:11:32 UTC (rev 6981) @@ -1,10 +1,12 @@ <chapter id="compatibility"> <title>Version Compatibility and Interoperability</title> + <section> + <title>API compatibility</title> <para> Within a major version, releases of JBoss Cache are meant to be compatible and interoperable. Compatible in the sense that it should be possible to - upgrade an application from one version to another by simply replacing the + upgrade an application from one version to another by simply replacing jars. Interoperable in the sense that if two different versions of JBoss Cache are used in the same cluster, they should be able to exchange replication and state transfer messages. Note however that interoperability @@ -15,22 +17,31 @@ <para> As such, JBoss Cache 2.x.x is not API or binary compatible with prior 1.x.x versions. - However, JBoss Cache 2.1.x will be API and binary compatible with 2.0.x. + On the other hand, JBoss Cache 2.1.x will be API and binary compatible with 2.0.x. </para> <para> - A configuration attribute, <literal>ReplicationVersion</literal>, is available and is used + We have made best efforts, however, to keep JBoss Cache 3.x both binary and API compatible with 2.x. Still, + it is recommended that client code is updated not to use deprecated methods, classes and configuration files. + </para> + </section> + <section> + <title>Wire-level interoperability</title> + + <para> + A configuration parameter, <literal>Configuration.setReplicationVersion()</literal>, is available and is used to control the wire format of inter-cache communications. They can be wound back from more efficient and newer protocols to "compatible" versions when talking to older releases. This mechanism allows us to improve JBoss Cache by using more efficient wire formats while still providing a means to preserve interoperability. </para> - + </section> <section> <title>Compatibility Matrix</title> <para> - A <ulink url="http://www.jboss.org/jbosscache/compatibility/index.html">compatibility matrix</ulink> is maintained on the JBoss Cache website, which contains information on - different versions of JBoss Cache, JGroups and JBoss AS. + A <ulink url="http://www.jboss.org/jbosscache/compatibility/index.html">compatibility matrix</ulink> is + maintained on the JBoss Cache website, which contains information on different versions of JBoss Cache, + JGroups and JBoss Application Server. </para> </section> Modified: core/trunk/src/main/docbook/userguide/en/modules/deployment.xml =================================================================== --- core/trunk/src/main/docbook/userguide/en/modules/deployment.xml 2008-10-17 17:17:17 UTC (rev 6980) +++ core/trunk/src/main/docbook/userguide/en/modules/deployment.xml 2008-10-17 18:11:32 UTC (rev 6981) @@ -1,7 +1,7 @@ <chapter id="deployment"> <title>Deploying JBoss Cache</title> <section id="deployment.standalone"> - <title>Standalone Use / Programatic Deployment</title> + <title>Standalone Use/Programatic Deployment</title> <para> When used in a standalone Java program, all that needs to be done is to instantiate the cache using the <literal>CacheFactory</literal> @@ -20,21 +20,19 @@ server wishes to programatically deploy a cache rather than relying on an application server's deployment features. An example of this would be a webapp deploying a cache via a - <literal>javax.servlet.ServletContextListener</literal> - . + <literal>javax.servlet.ServletContextListener</literal>. </para> <para> After creation, you could share your cache instance among different application components either by using an - IOC container such as Spring, JBoss Microcontainer, Picocontainer, etc., or by binding it to JNDI, or simply + IOC container such as Spring, JBoss Microcontainer, etc., or by binding it to JNDI, or simply holding a static reference to the cache. </para> <para> If, after deploying your cache you wish to expose a management interface to it in JMX, see the - <link linkend="jmx.registration.programatic">section on Programatic Registration in JMX</link> - . + <link linkend="jmx.registration.programatic">section on Programatic Registration in JMX</link>. </para> </section> <section id="deployment.microcontainer"> @@ -43,28 +41,23 @@ <para> Beginning with AS 5, JBoss AS supports deployment of POJO services via deployment of a file whose name ends with - <literal>-beans.xml</literal> - . + <literal>-beans.xml</literal>. A POJO service is one whose implementation is via a "Plain Old Java Object", meaning a simple java bean that isn't required to implement any special interfaces or extend any particular superclass. A - <literal>Cache</literal> - is a POJO service, and all the components in a + <literal>Cache</literal> is a POJO service, and all the components in a <literal>Configuration</literal> are also POJOs, so deploying a cache in this way is a natural step. </para> <para> Deployment of the cache is done using the JBoss Microcontainer that forms the core of JBoss AS. JBoss Microcontainer is a sophisticated IOC framework - (similar to Spring). A - <literal>-beans.xml</literal> - file is basically + similar to Spring. A <literal>-beans.xml</literal> file is basically a descriptor that tells the IOC framework how to assemble the various beans that make up a POJO service. </para> <para> - For each configurable option exposed by the - <literal>Configuration</literal> + For each configurable option exposed by the <literal>Configuration</literal> components, a getter/setter must be defined in the configuration class. This is required so that JBoss Microcontainer can, in typical IOC way, call these methods when the corresponding properties have been @@ -73,11 +66,11 @@ <para> You need to ensure that the <literal>jbosscache-core.jar</literal> and <literal>jgroups.jar</literal> libraries are in your server's <literal>lib</literal> directory. This is usually the case when you use JBoss AS in its - <literal>all</literal> configuration. Note that you will have to bring in any additional jars you require, such + <literal>all</literal> configuration. Note that you will have to bring in any optional jars you require, such as <literal>jdbm.jar</literal> based on your cache configuration. </para> <para> - Following is an example + The following is an example <literal>-beans.xml</literal> file. If you look in the @@ -121,10 +114,6 @@ <property name="lockAcquisitionTimeout">15000</property> <property name="exposeManagementStatistics">true</property> - - <property name="useRegionBasedMarshalling">true</property> - <property name="inactiveOnStartup">true</property> - </bean>  @@ -152,33 +141,22 @@ <literal>bean</literal> element represents an object and is used to create a <literal>Configuration</literal> - and its - <link linkend="configuration.elements">constituent parts</link> - . + and its <link linkend="configuration.elements">constituent parts</link>. </para> <para> An interesting thing to note in the above example is the use of the - <literal>RuntimeConfig</literal> - object. External resources like - a - <literal>TransactionManager</literal> - and a JGroups - <literal>ChannelFactory</literal> - that are visible to the - microcontainer are dependency injected into the - <literal>RuntimeConfig</literal> - . - The assumption here is that in some other deployment descriptor in the AS, - the referenced beans have been described. + <literal>RuntimeConfig</literal> object. External resources like a <literal>TransactionManager</literal> + and a JGroups <literal>ChannelFactory</literal> that are visible to the microcontainer are dependency injected + into the <literal>RuntimeConfig</literal>. The assumption here is that in some other deployment descriptor in + the AS, the referenced beans have already been described. </para> </section> <section> <title>Automatic binding to JNDI in JBoss AS</title> <para> - This feature is not available as of the time of this writing, - although it will be completed before AS 5.0.0.GA is released. - We will add a wiki page describing how to use it once it becomes available. + This feature is not available as of the time of this writing, although it will be completed before AS 5.0.0.GA + is released. We will add a wiki page describing how to use it once it becomes available. </para> </section> @@ -186,8 +164,7 @@ <title>Runtime Management Information</title> <para>JBoss Cache includes JMX MBeans to expose cache functionality and provide statistics that can be used to analyze cache operations. JBoss Cache can also broadcast cache events as MBean notifications for - handling - via JMX monitoring tools. + handling via JMX monitoring tools. </para> <section id="jmx.mbeans"> @@ -195,49 +172,35 @@ <para> JBoss Cache provides an MBean that can be registered with your environments JMX server to allow access to the cache instance via JMX. This MBean is the - <literal>org.jboss.cache.jmx.CacheJmxWrapper</literal> - . - It is a StandardMBean, so it's MBean interface is - <literal>org.jboss.cache.jmx.CacheJmxWrapperMBean</literal> - . + <literal>org.jboss.cache.jmx.CacheJmxWrapper</literal>. + It is a StandardMBean, so its MBean interface is <literal>org.jboss.cache.jmx.CacheJmxWrapperMBean</literal>. This MBean can be used to: <itemizedlist> - <listitem>Get a reference to the underlying - <literal>Cache</literal> - . + <listitem> + Get a reference to the underlying <literal>Cache</literal>. </listitem> - <listitem>Invoke create/start/stop/destroy lifecycle operations on - the underlying - <literal>Cache</literal> - . + <listitem> + Invoke create/start/stop/destroy lifecycle operations on the underlying <literal>Cache</literal>. </listitem> - <listitem>Inspect various details about the cache's current state (number of nodes, lock information, - etc.) + <listitem> + Inspect various details about the cache's current state (number of nodes, lock information, etc.) </listitem> - <listitem>See numerous details about the cache's configuration, and + <listitem> + See numerous details about the cache's configuration, and change those configuration items that can be changed when the cache has already been started. </listitem> </itemizedlist> - See the - <literal>CacheJmxWrapperMBean</literal> - javadoc for more details. + See the <literal>CacheJmxWrapperMBean</literal> javadoc for more details. </para> <para> - If a - <literal>CacheJmxWrapper</literal> - is registered, JBoss Cache also provides MBeans - for several other internal components and subsystems. These - MBeans are used to capture and expose statistics related to the subsystems they represent. They are hierarchically - associated with the - <literal>CacheJmxWrapper</literal> - MBean and have service names that reflect this relationship. For - example, a replication interceptor MBean for the - <literal>jboss.cache:service=TomcatClusteringCache</literal> - instance will be - accessible through the service named - <literal>jboss.cache:service=TomcatClusteringCache,cache-interceptor=ReplicationInterceptor</literal> - . + If a <literal>CacheJmxWrapper</literal> is registered, JBoss Cache also provides MBeans + for several other internal components and subsystems. These MBeans are used to capture and expose + statistics related to the subsystems they represent. They are hierarchically associated with the + <literal>CacheJmxWrapper</literal> MBean and have service names that reflect this relationship. For + example, a replication interceptor MBean for the <literal>jboss.cache:service=TomcatClusteringCache</literal> + instance will be accessible through the service named + <literal>jboss.cache:service=TomcatClusteringCache,cache-interceptor=ReplicationInterceptor</literal>. </para> </section> @@ -245,21 +208,18 @@ <title>Registering the CacheJmxWrapper with the MBeanServer</title> <para> - The best way to ensure the - <literal>CacheJmxWrapper</literal> - is registered - in JMX depends on how you are deploying your cache: + The best way to ensure the <literal>CacheJmxWrapper</literal> is registered in JMX depends on how you are + deploying your cache. </para> <section id="jmx.registration.programatic"> <title>Programatic Registration</title> + <section id="jmx.registration.programatic.construct"> + <title>With a Cache instance</title> <para> - Simplest way to do this is to create your - <literal>Cache</literal> - and pass it to the - <literal>CacheJmxWrapper</literal> - constructor. + Simplest way to do this is to create your <literal>Cache</literal> and pass it to the + <literal>CacheJmxWrapper</literal> constructor. </para> <programlisting role="JAVA"><![CDATA[ @@ -270,7 +230,7 @@ CacheJmxWrapperMBean wrapper = new CacheJmxWrapper(cache); MBeanServer server = getMBeanServer(); // however you do it - ObjectName on = new ObjectName("jboss.cache:service=TreeCache"); + ObjectName on = new ObjectName("jboss.cache:service=Cache"); server.registerMBean(wrapper, on); // Invoking lifecycle methods on the wrapper results @@ -287,17 +247,14 @@ wrapper.stop(); wrapper.destroy(); ]]></programlisting> + </section> + <section id="jmx.registration.programatic.cfg"> + <title>With a Configuration instance</title> <para> - Alternatively, build a - <literal>Configuration</literal> - object - and pass it to the - <literal>CacheJmxWrapper</literal> - . The wrapper - will construct the - <literal>Cache</literal> - : + Alternatively, build a <literal>Configuration</literal> object and pass it to the + <literal>CacheJmxWrapper</literal>. The wrapper will construct the <literal>Cache</literal> on your + behalf. </para> <programlisting role="JAVA"><![CDATA[ @@ -322,39 +279,16 @@ wrapper.stop(); wrapper.destroy(); ]]></programlisting> + </section> </section> <section> - <title>JMX-Based Deployment in JBoss AS (JBoss AS 4.x and 5.x)</title> - + <title>JMX-Based Deployment in JBoss AS (JBoss AS 5.x)</title> <para> - When you - <link linkend="deployment.microkernel">deploy your cache in JBoss AS using a -service.xml file</link> - , - a - <literal>CacheJmxWrapper</literal> - is automatically registered. There is no need - to do anything further. The - <literal>CacheJmxWrapper</literal> - is accessible from an MBean server - through the service name specified in the cache configuration file's - <literal>mbean</literal> - element. - </para> - </section> - - <section> - <title>Via JBoss Microcontainer (JBoss AS 5.x)</title> - - <para> - <literal>CacheJmxWrapper</literal> - is a POJO, so the microcontainer - has no problem creating one. The trick is - getting it to register your bean in JMX. This can be done by - specifying the + <literal>CacheJmxWrapper</literal> is a POJO, so the microcontainer has no problem creating one. The + trick is getting it to register your bean in JMX. This can be done by specifying the <literal>org.jboss.aop.microcontainer.aspects.jmx.JMX</literal> - annotation on the - <literal>CacheJmxWrapper</literal> + annotation on the <literal>CacheJmxWrapper</literal> bean: </para> @@ -373,8 +307,7 @@  <bean name="DefaultCacheFactory" class="org.jboss.cache.DefaultCacheFactory"> - <constructor factoryClass="org.jboss.cache.DefaultCacheFactory" - factoryMethod="getInstance"/> + <constructor factoryClass="org.jboss.cache.DefaultCacheFactory" /> </bean>  @@ -405,21 +338,11 @@ ]]></programlisting> <para> - As discussed in the - <link linkend="jmx.registration.programatic">Programatic Registration</link> - section, - <literal>CacheJmxWrapper</literal> - can do the work of building, - creating and starting the - <literal>Cache</literal> - if it is provided - with a - <literal>Configuration</literal> - . With the microcontainer, - this is the preferred approach, as it saves the boilerplate XML - needed to create the - <literal>CacheFactory</literal> - : + As discussed in the <link linkend="jmx.registration.programatic">Programatic Registration</link> + section, <literal>CacheJmxWrapper</literal> can do the work of building, creating and starting the + <literal>Cache</literal> if it is provided with a <literal>Configuration</literal>. With the + microcontainer, this is the preferred approach, as it saves the boilerplate XML + needed to create the <literal>CacheFactory</literal>. </para> <programlisting role="XML"><![CDATA[ @@ -456,30 +379,18 @@ <section id="jmx.statistics"> <title>JBoss Cache Statistics</title> <para> - JBoss Cache captures statistics in its interceptors and exposes the statistics through interceptor - MBeans. Gathering of statistics is enabled by default; this can be disabled for a specific cache - instance through the - <literal>ExposeManagementStatistics</literal> - configuration attribute. Note that - the majority of the statistics are provided by the - <literal>CacheMgmtInterceptor</literal> - , + JBoss Cache captures statistics in its interceptors and various other components, and exposes these + statistics through a set of MBeans. Gathering of statistics is enabled by default; this can be disabled for + a specific cache instance through the <literal>Configuration.setExposeManagementStatistics()</literal> + setter. Note that the majority of the statistics are provided by the <literal>CacheMgmtInterceptor</literal>, so this MBean is the most significant in this regard. If you want to disable all statistics for performance - reasons, you set - <literal>ExposeManagementStatistics</literal> - to - <literal>false</literal> - as this will - prevent the - <literal>CacheMgmtInterceptor</literal> - from being included in the cache's interceptor stack + reasons, you set <literal>Configuration.setExposeManagementStatistics(false)</literal> and this will + prevent the <literal>CacheMgmtInterceptor</literal> from being included in the cache's interceptor stack when the cache is started. </para> <para> - If a - <literal>CacheJmxWrapper</literal> - is registered with JMX, the wrapper also ensures that - an MBean is registered in JMX for each interceptor that exposes statistics + If a <literal>CacheJmxWrapper</literal> is registered with JMX, the wrapper also ensures that + an MBean is registered in JMX for each interceptor and component that exposes statistics. <footnote> <para> Note that if the @@ -493,57 +404,11 @@ that this sort of "discovery" of the JMX environment was beyond the proper scope of a caching library, so we removed this functionality. </para> - </footnote> - . + </footnote>. Management tools can then access those MBeans to examine the statistics. See the section in the <link linkend="jmx_reference.statistics">JMX Reference chapter</link> - pertaining to the - statistics that are made available via JMX. + pertaining to the statistics that are made available via JMX. </para> - <para> - The name under which the interceptor MBeans will be registered is derived by taking the - <literal>ObjectName</literal> - under which the - <literal>CacheJmxWrapper</literal> - is - registered and adding a - <literal>cache-interceptor</literal> - attribute key whose value - is the non-qualified name of the interceptor class. So, for example, if the - <literal>CacheJmxWrapper</literal> - were registered under - <literal>jboss.cache:service=TreeCache</literal> - , the name of the - <literal>CacheMgmtInterceptor</literal> - MBean would be - <literal>jboss.cache:service=TreeCache,cache-interceptor=CacheMgmtInterceptor</literal> - . - </para> - <para> - Each interceptor's MBean exposes a - <literal>StatisticsEnabled</literal> - attribute that can be used to disable maintenance of statistics for - that interceptor. In addition, each interceptor MBean provides the following common operations and - attributes. - <itemizedlist> - <listitem> - <literal>dumpStatistics</literal> - - returns a - <literal>Map</literal> - containing the interceptor's attributes and values. - </listitem> - <listitem> - <literal>resetStatistics</literal> - - resets all statistics maintained by the interceptor. - </listitem> - <listitem> - <literal>setStatisticsEnabled(boolean)</literal> - - allows statistics to be disabled for a specific interceptor. - </listitem> - </itemizedlist> - </para> - <para> - </para> </section> <section> @@ -552,24 +417,16 @@ JBoss Cache users can register a listener to receive cache events described earlier in the <link linkend="api.listener">User API</link> chapter. Users can alternatively utilize the cache's management information infrastructure to receive these - events - via JMX notifications. Cache events are accessible as notifications by registering a - <literal>NotificationListener</literal> - for the - <literal>CacheJmxWrapper</literal> - . + events via JMX notifications. Cache events are accessible as notifications by registering a + <literal>NotificationListener</literal> for the <literal>CacheJmxWrapper</literal>. </para> <para> - See the section in the - <link linkend="jmx_reference.notifications">JMX Reference chapter</link> - pertaining - to JMX notifications for a list of notifications that can be received through the - <literal>CacheJmxWrapper</literal> - . + See the section in the <link linkend="jmx_reference.notifications">JMX Reference chapter</link> + pertaining to JMX notifications for a list of notifications that can be received through the + <literal>CacheJmxWrapper</literal>. </para> - <para> The following is an example of how to programmatically receive cache notifications when running in a JBoss AS environment. In this example, the client uses a filter to specify which events are of interest. @@ -647,63 +504,37 @@ </section> - <section> - <title>Accessing Cache MBeans in a Standalone Environment</title> + <section id="jconsole"> + <title>Accessing Cache MBeans in a Standalone Environment using the <literal>jconsole</literal> Utility</title> <para> JBoss Cache MBeans are easily accessed when running cache instances in an application server that provides an MBean server interface such as JBoss JMX Console. Refer to your server documentation for instructions on how to access MBeans running in a server's MBean container. </para> <para> - In addition, though, JBoss Cache MBeans are also accessible when running in a non-server environment if the - JVM is JDK 5.0 or later. When running a standalone cache in a JDK 5.0 environment, you can access the - cache's MBeans as follows. + In addition, though, JBoss Cache MBeans are also accessible when running in a non-server environment using + your JDK's <literal>jconsole</literal> tool. When running a standalone cache outside of an application server, + you can access the cache's MBeans as follows. </para> <para> <orderedlist> <listitem> - Set the system property - <literal>-Dcom.sun.management.jmxremote</literal> - when starting the JVM - where the cache will run. + Set the system property <literal>-Dcom.sun.management.jmxremote</literal> + when starting the JVM where the cache will run. </listitem> <listitem> - Once the JVM is running, start the JDK 5.0 - <literal>jconsole</literal> - utility, located in your JDK's - <literal>/bin</literal> - directory. + Once the JVM is running, start the <literal>jconsole</literal> utility, located in your JDK's + <literal>/bin</literal> directory. </listitem> - <listitem>When the utility loads, you will be able to select your running JVM and connect to it. The - JBoss Cache - MBeans will be available on the MBeans panel. + <listitem> + When the utility loads, you will be able to select your running JVM and connect to it. The + JBoss Cache MBeans will be available on the MBeans panel. </listitem> </orderedlist> </para> - <para>Note that the - <literal>jconsole</literal> - utility will automatically register as a listener for cache notifications when - connected to a JVM running JBoss Cache instances. + <para>Note that the <literal>jconsole</literal> utility will automatically register as a listener for cache + notifications when connected to a JVM running JBoss Cache instances. </para> - - <para>The following figure shows cache interceptor MBeans in - <literal>jconsole</literal> - . Cache statistics are displayed - for the - <literal>CacheMgmtInterceptor</literal> - : - </para> - - <figure> - <title>CacheMgmtInterceptor MBean in jconsole</title> - - <mediaobject> - <imageobject> - <imagedata fileref="CacheMgmtInterceptor.png"/> - </imageobject> - </mediaobject> - </figure> - </section> </section> </chapter> Modified: core/trunk/src/main/docbook/userguide/en/modules/introduction.xml =================================================================== --- core/trunk/src/main/docbook/userguide/en/modules/introduction.xml 2008-10-17 17:17:17 UTC (rev 6980) +++ core/trunk/src/main/docbook/userguide/en/modules/introduction.xml 2008-10-17 18:11:32 UTC (rev 6981) @@ -38,7 +38,7 @@ </itemizedlist> </para> <para> - POJO Cache has a complete and separate set of documentation, including a user guide, FAQ and tutorial all + POJO Cache has a complete and separate set of documentation, including a Users' Guide, FAQ and tutorial all available on the JBoss Cache <ulink url="http://www.jboss.org/jbosscache">documentation website</ulink>. As such, POJO Cache will not be discussed further in this book. </para> Modified: core/trunk/src/main/docbook/userguide/en/modules/preface.xml =================================================================== --- core/trunk/src/main/docbook/userguide/en/modules/preface.xml 2008-10-17 17:17:17 UTC (rev 6980) +++ core/trunk/src/main/docbook/userguide/en/modules/preface.xml 2008-10-17 18:11:32 UTC (rev 6981) @@ -2,7 +2,7 @@ <title>Preface</title> <para> - This is the official JBoss Cache user guide. Along with its accompanying documents (an FAQ, a tutorial and a + This is the official JBoss Cache Users' Guide. Along with its accompanying documents (an FAQ, a tutorial and a whole set of documents on POJO Cache), this is freely available on the JBoss Cache <ulink url="http://www.jboss.org/jbosscache">documentation website</ulink>. </para> <para> Modified: core/trunk/src/main/docbook/userguide/en/modules/replication.xml =================================================================== --- core/trunk/src/main/docbook/userguide/en/modules/replication.xml 2008-10-17 17:17:17 UTC (rev 6980) +++ core/trunk/src/main/docbook/userguide/en/modules/replication.xml 2008-10-17 18:11:32 UTC (rev 6981) @@ -1,6 +1,6 @@ <?xml version="1.0" encoding="UTF-8"?> <chapter id="clustering"> - <title>Clustering</title> + <title>Cache Modes and Clustering</title> <para>This chapter talks about aspects around clustering JBoss Cache.</para> @@ -17,9 +17,7 @@ <title>Local Mode</title> <para>Local caches don't join a cluster and don't communicate with other - caches in a cluster. Therefore their elements don't need to be - serializable - however, we recommend making them serializable, enabling - a user to change the cache mode at any time. The dependency on the + caches in a cluster. The dependency on the JGroups library is still there, although a JGroups channel is not started. </para> @@ -30,11 +28,10 @@ <para>Replicated caches replicate all changes to some or all of the other cache instances in the cluster. Replication can either happen after each - modification (no transactions), or at the end of a transaction (commit - time). + modification (no transactions or batches), or at the end of a transaction or batch. </para> - <para>Replication can be synchronous or asynchronous . Use of either one + <para>Replication can be synchronous or asynchronous. Use of either one of the options is application dependent. Synchronous replication blocks the caller (e.g. on a <literal>put()</literal> @@ -45,7 +42,8 @@ returns immediately). JBoss Cache also offers a replication queue, where modifications are replicated periodically (i.e. interval-based), or when the queue size exceeds a number of elements, or - a combination thereof. + a combination thereof. A replication queue can therefore offer much higher performance as the actual + replication is performed by a background thread. </para> <para>Asynchronous replication is faster (no caller blocking), because @@ -360,51 +358,8 @@ <section> <title>Configuration</title> - <programlisting role="XML"><![CDATA[ - -<attribute name="BuddyReplicationConfig"> - <config> - -  - <buddyReplicationEnabled>true</buddyReplicationEnabled> - -  - <buddyLocatorClass>org.jboss.cache.buddyreplication.NextMemberBuddyLocator</buddyLocatorClass> - -  - <buddyLocatorProperties> - numBuddies = 1 - ignoreColocatedBuddies = true - </buddyLocatorProperties> - -  - <buddyPoolName>myBuddyPoolReplicationGroup</buddyPoolName> - -  - <buddyCommunicationTimeout>2000</buddyCommunicationTimeout> - -  - <dataGravitationRemoveOnFind>true</dataGravitationRemoveOnFind> - -  - <dataGravitationSearchBackupTrees>true</dataGravitationSearchBackupTrees> - -  - <autoDataGravitation>false</autoDataGravitation> - - </config> -</attribute> - -]]></programlisting> - </section> + See the <link linkend="configuration_reference_chapter">configuration reference section</link> for details on configuring buddy replication. + </section> </section> </section> </section> @@ -416,7 +371,7 @@ every time data is changed in a cache other caches in the cluster receive a message informing them that their data is now stale and should be evicted from memory. Invalidation, when used with a shared cache loader - (see chapter on Cache Loaders) would cause remote caches to refer to the + (see chapter on <link linkend="cache_loaders">cacahe loaders</link>) would cause remote caches to refer to the shared cache loader to retrieve modified data. The benefit of this is twofold: network traffic is minimised as invalidation messages are very small compared to replicating updated data, and also that other caches in @@ -425,7 +380,7 @@ </para> <para>Invalidation messages are sent after each modification (no - transactions), or at the end of a transaction, upon successful commit. + transactions or batches), or at the end of a transaction or batch, upon successful commit. This is usually more efficient as invalidation messages can be optimised for the transaction as a whole rather than on a per-modification basis. @@ -579,7 +534,7 @@ cluster, it becomes the buddy of one or more other instances, and one or more other instances become its buddy. Each time an instance determines it has a new buddy providing backup for it, it pushes - it's current state to the new buddy. This "pushing" of state to the + its current state to the new buddy. This "pushing" of state to the new buddy is slightly different from other forms of state transfer, which are based on a "pull" approach (i.e. recipient asks for and receives state). However, the process of preparing and integrating Modified: core/trunk/src/main/docbook/userguide/en/modules/transactions.xml =================================================================== --- core/trunk/src/main/docbook/userguide/en/modules/transactions.xml 2008-10-17 17:17:17 UTC (rev 6980) +++ core/trunk/src/main/docbook/userguide/en/modules/transactions.xml 2008-10-17 18:11:32 UTC (rev 6981) @@ -161,7 +161,7 @@ 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 + and its corresponding javadocs for details. </para> </section> Modified: core/trunk/src/main/java/org/jboss/cache/Cache.java =================================================================== --- core/trunk/src/main/java/org/jboss/cache/Cache.java 2008-10-17 17:17:17 UTC (rev 6980) +++ core/trunk/src/main/java/org/jboss/cache/Cache.java 2008-10-17 18:11:32 UTC (rev 6981) @@ -23,6 +23,7 @@ import net.jcip.annotations.ThreadSafe; import org.jboss.cache.config.Configuration; +import org.jboss.cache.interceptors.base.CommandInterceptor; import org.jgroups.Address; import java.util.List; @@ -535,4 +536,43 @@ * @since 3.0 */ void endBatch(boolean successful); + + /** + * Adds a custom interceptor to the interceptor chain, at specified position, where the first interceptor in the chain + * is at position 0 and the last one at getInterceptorChain().size() - 1. + * + * @param i the interceptor to add + * @param position the position to add the interceptor + * + * @since 3.0 + */ + void addInterceptor(CommandInterceptor i, int position); + + /** + * Adds a custom interceptor to the interceptor chain, after an instance of the specified interceptor type. Throws a + * cache exception if it cannot find an interceptor of the specified type. + * + * @param i interceptor to add + * @param afterInterceptor interceptor type after which to place custom interceptor + * + * @since 3.0 + */ + void addInterceptor(CommandInterceptor i, Class<? extends CommandInterceptor> afterInterceptor); + + /** + * Removes the interceptor at a specified position, where the first interceptor in the chain + * is at position 0 and the last one at getInterceptorChain().size() - 1. + * + * @param position the position at which to remove an interceptor + * @since 3.0 + */ + void removeInterceptor(int position); + + /** + * Removes the interceptor of specified type. + * + * @param interceptorType type of interceptor to remove + * @since 3.0 + */ + void removeInterceptor(Class<? extends CommandInterceptor> interceptorType); } Modified: core/trunk/src/main/java/org/jboss/cache/CacheSPI.java =================================================================== --- core/trunk/src/main/java/org/jboss/cache/CacheSPI.java 2008-10-17 17:17:17 UTC (rev 6980) +++ core/trunk/src/main/java/org/jboss/cache/CacheSPI.java 2008-10-17 18:11:32 UTC (rev 6981) @@ -120,39 +120,6 @@ Marshaller getMarshaller(); /** - * Adds a custom interceptor to the interceptor chain, at specified position, where the first interceptor in the chain - * is at position 0 and the last one at getInterceptorChain().size() - 1. - * - * @param i the interceptor to add - * @param position the position to add the interceptor - */ - void addInterceptor(CommandInterceptor i, int position); - - /** - * Adds a custom interceptor to the interceptor chain, after an instance of the specified interceptor type. Throws a - * cache exception if it cannot find an interceptor of the specified type. - * - * @param i interceptor to add - * @param afterInterceptor interceptor type after which to place custom interceptor - */ - void addInterceptor(CommandInterceptor i, Class<? extends CommandInterceptor> afterInterceptor); - - /** - * Removes the interceptor at a specified position, where the first interceptor in the chain - * is at position 0 and the last one at getInterceptorChain().size() - 1. - * - * @param position the position at which to remove an interceptor - */ - void removeInterceptor(int position); - - /** - * Removes the interceptor of specified type. - * - * @param interceptorType type of interceptor to remove - */ - void removeInterceptor(Class<? extends CommandInterceptor> interceptorType); - - /** * Retrieves the current CacheCacheLoaderManager instance associated with the current Cache instance. * <p/> * From 2.1.0, Interceptor authors should obtain this by injection rather than this method. See the

17 years

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosscache-commits October 2008