[jbosscache-commits] JBoss Cache SVN: r6936 - in core/trunk/src/main/docbook/userguide/en: modules and 1 other directory.
jbosscache-commits at lists.jboss.org
jbosscache-commits at lists.jboss.org
Tue Oct 14 13:12:01 EDT 2008
Author: manik.surtani at jboss.com
Date: 2008-10-14 13:12:01 -0400 (Tue, 14 Oct 2008)
New Revision: 6936
Added:
core/trunk/src/main/docbook/userguide/en/modules/batching.xml
Modified:
core/trunk/src/main/docbook/userguide/en/master.xml
core/trunk/src/main/docbook/userguide/en/modules/basic_api.xml
core/trunk/src/main/docbook/userguide/en/modules/configuration.xml
core/trunk/src/main/docbook/userguide/en/modules/introduction.xml
core/trunk/src/main/docbook/userguide/en/modules/preface.xml
Log:
Updated a PART of the userguide
Modified: core/trunk/src/main/docbook/userguide/en/master.xml
===================================================================
--- core/trunk/src/main/docbook/userguide/en/master.xml 2008-10-14 15:17:56 UTC (rev 6935)
+++ core/trunk/src/main/docbook/userguide/en/master.xml 2008-10-14 17:12:01 UTC (rev 6936)
@@ -14,6 +14,7 @@
<!ENTITY deployment SYSTEM "modules/deployment.xml">
<!ENTITY configuration_reference SYSTEM "modules/configuration_reference.xml">
<!ENTITY jmx_reference SYSTEM "modules/jmx_reference.xml">
+ <!ENTITY batching SYSTEM "modules/batching.xml">
]>
<book lang="en">
<bookinfo>
@@ -98,6 +99,7 @@
&basic_api;
&configuration;
&deployment;
+ &batching;
&compatibility;
</part>
Modified: core/trunk/src/main/docbook/userguide/en/modules/basic_api.xml
===================================================================
--- core/trunk/src/main/docbook/userguide/en/modules/basic_api.xml 2008-10-14 15:17:56 UTC (rev 6935)
+++ core/trunk/src/main/docbook/userguide/en/modules/basic_api.xml 2008-10-14 17:12:01 UTC (rev 6936)
@@ -30,8 +30,8 @@
</para>
<para>
- Reviewing the javadoc for the above interfaces is the best way
- to learn the API. Below we cover some of the main points.
+ Note that the diagram above only depicts some of the more popular API methods. Reviewing the javadoc for the
+ above interfaces is the best way to learn the API. Below, we cover some of the main points.
</para>
</section>
@@ -42,8 +42,7 @@
<literal>Cache</literal>
interface can only be created
via a
- <literal>CacheFactory</literal>
- . (This is unlike JBoss Cache 1.x,
+ <literal>CacheFactory</literal>. (This is unlike JBoss Cache 1.x,
where an instance of the old
<literal>TreeCache</literal>
class could
@@ -136,7 +135,7 @@
simple reads and writes to that node.
</para>
<programlisting role="JAVA"><![CDATA[
- // Let's get ahold of the root node.
+ // Let's get a hold of the root node.
Node rootNode = cache.getRoot();
// Remember, JBoss Cache stores data in a tree structure.
@@ -248,48 +247,18 @@
// under the 'people' section of the tree
// Parse it from a String
- Fqn<String> abc = Fqn.fromString("/people/Smith/Joe/");
+ Fqn abc = Fqn.fromString("/people/Smith/Joe/");
- // Build it directly. Marginally more efficient to construct than parsing
- String[] strings = new String[] { "people", "Smith", "Joe" };
- Fqn<String> abc = new Fqn<String>(strings);
-
// Here we want to use types other than String
- Object[] objs = new Object[]{ "accounts", "NY", new Integer(12345) };
- Fqn<Object> acctFqn = new Fqn<Object>(objs);
+ Fqn acctFqn = Fqn.fromElements("accounts", "NY", new Integer(12345));
]]></programlisting>
<para>Note that</para>
- <programlisting role="JAVA"><![CDATA[Fqn<String> f = new Fqn<String>("/a/b/c");]]></programlisting>
- <para>is
- <emphasis>not</emphasis>
- the same as
+ <programlisting role="JAVA"><![CDATA[Fqn f = Fqn.fromElements("a", "b", "c");]]></programlisting>
+ <para>is the same as
</para>
- <programlisting role="JAVA"><![CDATA[Fqn<String> f = Fqn.fromString("/a/b/c");]]></programlisting>
+ <programlisting role="JAVA"><![CDATA[Fqn f = Fqn.fromString("/a/b/c");]]></programlisting>
- <para>
- The former will result in an Fqn with a single element, called "/a/b/c"
- which hangs directly under the cache root. The latter will result
- in a 3 element Fqn, where "c" idicates a child of "b", which is a child
- of "a", and "a" hangs off the cache root. Another way to
- look at it is that the "/" separarator is only parsed when it forms
- part of a String passed in to
- <literal>Fqn.fromString()</literal>
- and not
- otherwise.
- </para>
-
- <para>
- The JBoss Cache API in the 1.x releases included many overloaded
- convenience methods that took a string in the
- <literal>/a/b/c</literal>
- format in place
- of an
- <literal>Fqn</literal>
- . In the interests of API simplicity, no
- such convenience methods are available in the JBC 2.x API.
- </para>
-
</section>
<section>
@@ -345,9 +314,7 @@
<listitem>
<emphasis>LOCAL</emphasis>
- local, non-clustered cache. Local caches don't join a cluster and don't
- communicate with other caches in a cluster. Therefore their contents don't need to be Serializable;
- however, we recommend making them Serializable, allowing you the flexibility to change the cache mode at
- any time.
+ communicate with other caches in a cluster.
</listitem>
<listitem>
<emphasis>REPL_SYNC</emphasis>
@@ -509,6 +476,16 @@
<listitem>
<para>
+ <literal>@NodeInvalidated</literal>
+ - methods annotated such receive a notification when a node is
+ evicted from memory due to a remote invalidation event. Methods need to accept a parameter type which is assignable from
+ <literal>NodeInvalidatedEvent</literal>
+ .
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
<literal>@NodeActivated</literal>
- methods annotated such receive a notification when a node is
activated. Methods need to accept a parameter type which is assignable from
@@ -583,6 +560,14 @@
</para>
</listitem>
+ <listitem>
+ <para>
+ <literal>@BuddyGroupChanged</literal>
+ - methods annotated such receive a notification when a node changes its buddy group, perhaps due
+ to a buddy falling out of the cluster or a newer, closer buddy joining.
+ Methods need to accept a parameter type which is assignable from <literal>BuddyGroupChangedEvent</literal>.
+ </para>
+ </listitem>
</itemizedlist>
</para>
<para>
@@ -654,34 +639,34 @@
</listitem>
<listitem>
<literal>org.jboss.cache.loader.JdbmCacheLoader</literal>
- - an upcoming open source alternative to the BerkeleyDB.
+ - an open source alternative to the BerkeleyDB.
</listitem>
<listitem>
<literal>org.jboss.cache.loader.tcp.TcpCacheLoader</literal>
- - uses a TCP socket to "persist" data to a remote cluster, using a "far cache" pattern.
- <footnote>
- <para>http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossClusteringPatternFarCache</para>
- </footnote>
+ - uses a TCP socket to "persist" data to a remote cluster, using <ulink url="http://www.jboss.org/community/docs/DOC-10292">a "far cache" pattern</ulink>.
</listitem>
<listitem>
<literal>org.jboss.cache.loader.ClusteredCacheLoader</literal>
- - used as a "read-only" CacheLoader, where other nodes in the cluster are queried for state.
+ - used as a "read-only" cache loader, where other nodes in the cluster are queried for state. Useful when full
+ state transfer is too expensive and it is preferred that state is lazily loaded.
</listitem>
</itemizedlist>
- These CacheLoaders, along with advanced aspects and tuning issues, are discussed in the
- <link linkend="cache_loaders">chapter dedicated to CacheLoaders</link>
- .
+ These cache loaders, along with advanced aspects and tuning issues, are discussed in the
+ <link linkend="cache_loaders">chapter dedicated to cache loaders</link>.
</para>
</section>
<section>
<title>Using Eviction Policies</title>
<para>
- Eviction policies are the counterpart to CacheLoaders. They are necessary to make sure the cache does not run
+ Eviction policies are the counterpart to cache loaders. They are necessary to make sure the cache does not run
out of memory and when the cache starts to fill,
- the eviction algorithm running in a separate thread offloads in-memory state to the CacheLoader and frees up
- memory. Eviction policies can be configured
- on a per-region basis, so different subtrees in the cache could have different eviction preferences.
+ an eviction algorithm running in a separate thread evicts in-memory state and frees up
+ memory. If configured with a cache loader, the state can then be retrieved from the cache loader if needed.
+ </para>
+ <para>
+ Eviction policies can be configured on a per-region basis, so different subtrees in the cache could have
+ different eviction preferences.
JBoss Cache ships with several eviction policies:
<itemizedlist>
@@ -714,8 +699,7 @@
</listitem>
</itemizedlist>
Detailed configuration and implementing custom eviction policies are discussed in the
- <link linkend="eviction_policies">chapter dedicated to eviction policies.</link>
- .
+ <link linkend="eviction_policies">chapter dedicated to eviction policies</link>.
</para>
</section>
</chapter>
Added: core/trunk/src/main/docbook/userguide/en/modules/batching.xml
===================================================================
--- core/trunk/src/main/docbook/userguide/en/modules/batching.xml (rev 0)
+++ core/trunk/src/main/docbook/userguide/en/modules/batching.xml 2008-10-14 17:12:01 UTC (rev 6936)
@@ -0,0 +1,60 @@
+<chapter id="batching">
+ <title>Batching API</title>
+ <section id="batching.intro">
+ <title>Introduction</title>
+ <para>
+ The batching API, introduced in JBoss Cache 3.x, is intended as a mechanism to batch the way calls are replicated
+ independent of JTA transactions.
+ </para>
+ <para>
+ This is useful when you want to batch up replication calls within a scope finer than that of any ongoing JTA transactions.
+ </para>
+ </section>
+ <section id="batching.configuring">
+ <title>Configuring batching</title>
+ <para>
+ To use batching, you need to enable invocation batching in your cache configuration, either on the <literal>Configuration</literal> object:
+ </para>
+ <programlisting role="JAVA"><![CDATA[
+ Configuration.setInvocationBatchingEnabled(true);
+ ]]></programlisting>
+ <para>
+ or in your XML file:
+ </para>
+ <programlisting role="XML"><![CDATA[
+ <invocationBatching enabled="true"/>
+ ]]></programlisting>
+ <para>
+ By default, invocation batching is disabled. Note that you do <emphasis>not</emphasis> have to have a transaction
+ manager defined to use batching.
+ </para>
+ </section>
+
+ <section id="batching.api">
+ <title>Batching API</title>
+ <para>
+ Once you have configured your cache to use batching, you use it by calling <literal>startBatch()</literal>
+ and <literal>endBatch()</literal> on <literal>Cache</literal>. E.g.,
+ </para>
+ <programlisting role="JAVA"><![CDATA[
+ Cache cache = getCache();
+
+ // not using a batch
+ cache.put("/a", "key", "value"); // will replicate immediately
+
+ // using a batch
+ cache.startBatch();
+ cache.put("/a", "key", "value");
+ cache.put("/b", "key", "value");
+ cache.put("/c", "key", "value");
+ cache.endBatch(true); // This will now replicate the modifications since the batch was started.
+
+ cache.startBatch();
+ cache.put("/a", "key", "value");
+ cache.put("/b", "key", "value");
+ cache.put("/c", "key", "value");
+ cache.endBatch(false); // This will "discard" changes made in the batch
+
+ ]]></programlisting>
+ </section>
+</chapter>
\ No newline at end of file
Modified: core/trunk/src/main/docbook/userguide/en/modules/configuration.xml
===================================================================
--- core/trunk/src/main/docbook/userguide/en/modules/configuration.xml 2008-10-14 15:17:56 UTC (rev 6935)
+++ core/trunk/src/main/docbook/userguide/en/modules/configuration.xml 2008-10-14 17:12:01 UTC (rev 6936)
@@ -62,89 +62,45 @@
</para>
<para>
- Here is a simple example configuration file:
+ The simplest example of a configuration XML file, a cache configured to run in LOCAL mode, looks like this:
</para>
<programlisting role="XML"><![CDATA[
+
<?xml version="1.0" encoding="UTF-8"?>
-<!-- ===================================================================== -->
-<!-- -->
-<!-- Sample JBoss Cache Service Configuration -->
-<!-- -->
-<!-- ===================================================================== -->
+<jbosscache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+ xmlns="urn:jboss:jbosscache-core:config:3.0">
+</jbosscache>
-<server>
-
- <mbean code="org.jboss.cache.jmx.CacheJmxWrapper" name="jboss.cache:service=Cache">
-
- <!-- Configure the TransactionManager -->
- <attribute name="TransactionManagerLookupClass">
- org.jboss.cache.transaction.GenericTransactionManagerLookup
- </attribute>
- <!-- Node locking level : SERIALIZABLE
- REPEATABLE_READ (default)
- READ_COMMITTED
- READ_UNCOMMITTED
- NONE -->
- <attribute name="IsolationLevel">READ_COMMITTED</attribute>
-
- <!-- Lock parent before doing node additions/removes -->
- <attribute name="LockParentForChildInsertRemove">true</attribute>
-
- <!-- Valid modes are LOCAL (default)
- REPL_ASYNC
- REPL_SYNC
- INVALIDATION_ASYNC
- INVALIDATION_SYNC -->
- <attribute name="CacheMode">LOCAL</attribute>
-
- <!-- Max number of milliseconds to wait for a lock acquisition -->
- <attribute name="LockAcquisitionTimeout">15000</attribute>
-
-
- <!-- Specific eviction policy configurations. This is LRU -->
- <attribute name="EvictionConfig">
- <config>
- <attribute name="wakeUpIntervalSeconds">5</attribute>
- <attribute name="policyClass">org.jboss.cache.eviction.LRUPolicy</attribute>
-
- <!-- Cache wide default -->
- <region name="/_default_">
- <attribute name="maxNodes">5000</attribute>
- <attribute name="timeToLiveSeconds">1000</attribute>
- </region>
- </config>
- </attribute>
- </mbean>
-</server>
]]></programlisting>
<para>
- Another, more complete, sample XML file is included in the
+ This file uses sensible defaults for isolation levels, lock acquisition timeouts, locking modes, etc. Another,
+ more complete, sample XML file is included in the
<link linkend="sample_xml_file">configuration reference</link>
section of this book,
along with
<link linkend="configuration_reference">a handy look-up table</link>
explaining the various options.
</para>
+ <section id="configuration.validation">
+ <title>Validating Configuration Files</title>
+ <para>
+ By default JBoss Cache will validate your XML configuration file against an XML schema and throw an
+ exception if the configuration is invalid. This can be overridden with the <literal>-Djbosscache.config.validate=false</literal>
+ JVM parameter. Alternately, you could specify your own schema to validate against, using the
+ <literal>-Djbosscache.config.schemaLocation=url</literal> parameter.
+ </para>
+ <para>
+ By default though, configuration files are validated against the JBoss Cache configuration schema, which is
+ included in the <literal>jbosscache-core.jar</literal> or on <literal>http://www.jboss.org/jbosscache/jbosscache-config-3.0.xsd</literal>.
+ Most XML editing tools can be used with this schema to ensure the configuration file you create is correct
+ and valid.
+ </para>
+ </section>
<para>
- For historical reasons, the format of the JBoss Cache configuraton
- file follows that of a JBoss AS Service Archive (SAR) deployment
- descriptor (and still can be used as such
- <link linkend="deployment.microkernel">inside JBoss AS</link>
- ). Because
- of this dual usage, you may see elements in some configuration files
- (such as
- <literal>depends</literal>
- or
- <literal>classpath</literal>
- ) that are
- not relevant outside JBoss AS. These can safely be ignored.
- </para>
-
- <para>
Here's how you tell the
<literal>CacheFactory</literal>
to create
@@ -174,43 +130,13 @@
defaults and can even be used as-is for a quick start.
</para>
- <para>
- Following is an example of programatically creating a
- <literal>Configuration</literal>
- configured to match the one produced
- by the XML example above, and then using it to create a
- <literal>Cache</literal>
- :
- </para>
-
<programlisting role="JAVA"><![CDATA[
Configuration config = new Configuration();
- String tmlc = GenericTransactionManagerLookup.class.getName();
- config.setTransactionManagerLookupClass(tmlc);
+ config.setTransactionManagerLookupClass( GenericTransactionManagerLookup.class.getName() );
config.setIsolationLevel(IsolationLevel.READ_COMMITTED);
config.setCacheMode(CacheMode.LOCAL);
- config.setLockParentForChildInsertRemove(true);
config.setLockAcquisitionTimeout(15000);
- EvictionConfig ec = new EvictionConfig();
- ec.setWakeupIntervalSeconds(5);
- ec.setDefaultEvictionPolicyClass(LRUPolicy.class.getName());
-
- EvictionRegionConfig erc = new EvictionRegionConfig();
- erc.setRegionName("_default_");
-
- LRUConfiguration lru = new LRUConfiguration();
- lru.setMaxNodes(5000);
- lru.setTimeToLiveSeconds(1000);
-
- erc.setEvictionPolicyConfig(lru);
-
- List<EvictionRegionConfig> ercs = new ArrayList<EvictionRegionConfig>();
- ercs.add(erc);
- ec.setEvictionRegionConfigs(erc);
-
- config.setEvictionConfig(ec);
-
CacheFactory factory = new DefaultCacheFactory();
Cache cache = factory.createCache(config);
]]></programlisting>
@@ -247,7 +173,7 @@
class and its
<link linkend="configuration.elements">component parts</link>
are all Java Beans that expose all config elements via simple setters
- and getters. Therefore, any good IOC framework should be able to
+ and getters. Therefore, any good IOC framework such as Spring, Google Guice, JBoss Microcontainer, etc. should be able to
build up a
<literal>Configuration</literal>
from an XML file in
@@ -328,14 +254,14 @@
</listitem>
<listitem>
- <literal>EvictionPolicyConfig</literal>
+ <literal>EvictionAlgorithmConfig</literal>
: implementation-specific
configuration object for the
- <literal>EvictionPolicy</literal>
+ <literal>EvictionAlgorithm</literal>
implementation
being used. What configuration elements are exposed depends on
the needs of the
- <literal>EvictionPolicy</literal>
+ <literal>EvictionAlgorithm</literal>
implementation.
</listitem>
Modified: core/trunk/src/main/docbook/userguide/en/modules/introduction.xml
===================================================================
--- core/trunk/src/main/docbook/userguide/en/modules/introduction.xml 2008-10-14 15:17:56 UTC (rev 6935)
+++ core/trunk/src/main/docbook/userguide/en/modules/introduction.xml 2008-10-14 17:12:01 UTC (rev 6936)
@@ -6,30 +6,38 @@
<title>What is JBoss Cache?</title>
<para>
- JBoss Cache is a tree-structured, clustered, transactional cache. It is
- the backbone for many fundamental JBoss Application Server clustering services, including - in certain
- versions - clustering JNDI, HTTP and EJB sessions.
+ JBoss Cache is a tree-structured, clustered, transactional cache. It can be used in a standalone, non-clustered
+ environment, to cache frequently accessed data in memory thereby removing data retrieval or calculation bottlenecks
+ while providing "enterprise" features such as JTA compatibility, eviction and persistence.
+ </para>
+ <para>
+ JBoss Cache is also a clustered cache, and can be used in a cluster to replicate state providing a high degree
+ of failover. A variety of replication modes are supported, including invalidation and buddy replication, and
+ network communications can either be synchronous or asynchronous.
+ </para>
+ <para>
+ When used in a clustered mode, the cache is an effective mechanism of building high availability, fault
+ tolerance and even load balancing into custom applications and frameworks. For example, the JBoss Application
+ Server makes extensive use of JBoss Cache in clustering services such as HTTP and <ulink url="http://java.sun.com/products/ejb/">EJB</ulink> sessions, as well as
+ providing a distributed entity cache for <ulink url="http://en.wikipedia.org/wiki/Java_Persistence_API">JPA</ulink>.
</para>
<para>
- JBoss Cache can also be used as a standalone transactional and clustered caching library or even an object
- oriented data store. It can even be embedded in other enterprise Java frameworks and application servers
- such as BEA WebLogic or IBM WebSphere, Tomcat, Spring, Hibernate, and many others. It is also very commonly
- used directly by standalone Java applications that do not run from within an application server, to maintain
- clustered state.
+ JBoss Cache can - and often is - used outside of JBoss AS, in other Java EE environments such as Spring, Tomcat,
+ Glassfish, BEA WebLogic, IBM WebSphere, and even in standalone Java programs thanks to its minimal dependency set.
</para>
<section>
- <title>And what is Pojo Cache?</title>
+ <title>And what is POJO Cache?</title>
<para>
- Pojo Cache is an extension of the core JBoss Cache API. Pojo Cache offers additional functionality such as:
+ POJO Cache is an extension of the core JBoss Cache API. POJO Cache offers additional functionality such as:
<itemizedlist>
<listitem>maintaining object references even after replication or persistence.</listitem>
<listitem>fine grained replication, where only modified object fields are replicated.</listitem>
- <listitem>"API-less" clustering model where pojos are simply annotated as being clustered.</listitem>
+ <listitem>"API-less" clustering model where POJOs are simply annotated as being clustered.</listitem>
</itemizedlist>
</para>
<para>
- Pojo Cache has a complete and separate set of documentation, including a user guide, FAQ and tutorial and
- as such, Pojo Cache is not discussed further in this book.
+ POJO Cache has a complete and separate set of documentation, including a user guide, FAQ and tutorial and
+ as such, POJO Cache is not discussed further in this book.
</para>
</section>
@@ -42,6 +50,7 @@
JBoss Cache offers a simple and straightforward API, where data (simple Java objects) can be placed in the
cache and, based on configuration options selected, this data may be one or all of:
<itemizedlist>
+ <listitem>cached in-memory for efficient, threadsafe retrieval.</listitem>
<listitem>replicated to some or all cache instances in a cluster.</listitem>
<listitem>persisted to disk and/or a remote cluster ("far-cache").</listitem>
<listitem>garbage collected from memory when memory runs low, and passivated to disk so state isn't lost.
@@ -51,7 +60,7 @@
<itemizedlist>
<listitem>being able to participate in JTA transactions (works with Java EE compliant TransactionManagers).
</listitem>
- <listitem>attach to JMX servers and provide runtime statistics on the state of the cache.</listitem>
+ <listitem>attach to JMX consoles and provide runtime statistics on the state of the cache.</listitem>
<listitem>allow client code to attach listeners and receive notifications on cache events.</listitem>
</itemizedlist>
</para>
@@ -59,8 +68,7 @@
<para>A cache is organised as a tree, with a single root. Each node in the tree essentially contains a Map,
which acts as a store for key/value pairs. The only requirement placed on objects that are cached is that
they implement
- <literal>java.io.Serializable</literal>
- . Note that this requirement does not exist for Pojo Cache.
+ <literal>java.io.Serializable</literal>.
</para>
<para>JBoss Cache
@@ -81,8 +89,7 @@
anything, resulting in no network traffic.
</para>
- <para>If a caller has no transaction associated with it (and isolation level is not
- NONE - more about this later), we will replicate right after each modification, e.g. in the above
+ <para>If a caller has no transaction associated with it, we will replicate right after each modification, e.g. in the above
case we would send 100 messages, plus an additional message for the
rollback. In this sense, running without a transaction can be thought of as analogous as running with
auto-commit switched on in JDBC terminology, where each operation is committed automatically.
@@ -94,12 +101,19 @@
</para>
<para>
- The cache is also completely thread-safe. It uses a pessimistic locking scheme for nodes in the tree by
- default, with an optimistic locking scheme as a configurable option. With pessimistic locking, the degree
- of concurrency can be tuned using a number of isolation levels, corresponding to database-style
- transaction isolation levels, i.e., SERIALIZABLE, REPEATABLE_READ, READ_COMMITTED, READ_UNCOMMITTED and NONE.
- Concurrency, locking and isolation levels will be discussed later.
+ The cache is also completely thread-safe. It uses multi-versioned concurrency control (MVCC) to ensure thread
+ safety between readers and writers, while maintaining a high degree of concurrency. The specific MVCC implementation
+ used in JBoss Cache allows for readers to be completely free of locks and synchronized blocks, ensuring a very high
+ degree of performance for read-heavy applications.
+ </para>
+ <para>
+ Optimistic and pessimistic locking schemes, from older versions of JBoss Cache, are still available but are
+ deprecated in favour of MVCC, and will be removed in future releases.
</para>
+ <para>
+ The JBoss Cache MVCC implementation supports READ_COMMITTED and REPEATABLE_READ isolation levels, corresponding
+ to their database equivalents.
+ </para>
</section>
<section>
@@ -111,22 +125,19 @@
</para>
<para>
However, there is a way to build JBoss Cache as a Java 1.4.x compatible binary using
- <ulink url="http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossRetro">JBossRetro</ulink>
+ <ulink url="http://www.jboss.org/community/docs/DOC-10738">JBossRetro</ulink>
to retroweave the Java 5.0 binaries. However, Red Hat Inc. does not offer professional support around the
retroweaved
binary at this time and the Java 1.4.x compatible binary is not in the binary distribution. See
- <ulink url="http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCacheHabaneroJava1.4">this wiki</ulink>
+ <ulink url="http://www.jboss.org/community/docs/DOC-10263">this wiki</ulink>
page for
details on building the retroweaved binary for yourself.
</para>
<para>
In addition to Java 5.0, at a minimum, JBoss Cache has dependencies on
<ulink url="http://www.jgroups.org">JGroups</ulink>
- , and Apache's
- <ulink
- url="http://jakarta.apache.org/commons/logging/">commons-logging
- </ulink>
- . JBoss Cache ships with all dependent libraries necessary to run out of the box.
+ , and Apache's <ulink url="http://jakarta.apache.org/commons/logging/">commons-logging</ulink>.
+ JBoss Cache ships with all dependent libraries necessary to run out of the box.
</para>
</section>
@@ -138,9 +149,6 @@
<ulink url="http://www.gnu.org/copyleft/lesser.html">LGPL license.</ulink>
Commercial development support, production support and training for JBoss Cache is available through
<ulink url="http://www.jboss.com">JBoss, a division of Red Hat Inc.</ulink>
- JBoss Cache is a part of JBoss Professional Open Source
- <ulink url="http://www.jboss.comindex">JEMS</ulink>
- (JBoss Enterprise Middleware Suite).
</para>
</section>
</chapter>
Modified: core/trunk/src/main/docbook/userguide/en/modules/preface.xml
===================================================================
--- core/trunk/src/main/docbook/userguide/en/modules/preface.xml 2008-10-14 15:17:56 UTC (rev 6935)
+++ core/trunk/src/main/docbook/userguide/en/modules/preface.xml 2008-10-14 17:12:01 UTC (rev 6936)
@@ -3,26 +3,26 @@
<para>
This is the official JBoss Cache user guide. Along with its accompanying documents (an FAQ, a tutorial and a
- whole set of documents on PojoCache), this is freely available on the JBoss Cache <ulink url="http://labs.jboss.com/jbosscache">documentation site.</ulink>
+ whole set of documents on POJO Cache), this is freely available on the JBoss Cache <ulink url="http://labs.jboss.com/jbosscache">documentation site.</ulink>
</para>
<para>
When used, JBoss Cache refers to JBoss Cache Core, a tree-structured, clustered, transactional cache.
- Pojo Cache, also a part of the JBoss Cache distribution, is documented separately. (Pojo Cache is a cache that
- deals with Plain Old Java Objects, complete with object relationships, with the ability to cluster such pojos
- while maintaining their relationships. Please see the Pojo Cache documentation for more information about this.)
+ POJO Cache, also a part of the JBoss Cache distribution, is documented separately. (POJO Cache is a cache that
+ deals with Plain Old Java Objects, complete with object relationships, with the ability to cluster such POJOs
+ while maintaining their relationships. Please see the POJO Cache documentation for more information about this.)
</para>
<para>
- This book is targeted at both developers wishing to use JBoss Cache as a clustering and caching library in
- their codebase, as well as people who wish to "OEM" JBoss Cache by building on and extending its features. As
- such,
- this book is split into two major sections - one detailing the "User" API and the other going much deeper into
- specialist topics and the JBoss Cache architecture.
+ This book is targeted at developers wishing to use JBoss Cache as either a standalone in-memory cache,
+ a distributed or replicated cache, a clustering library, or an in-memory database. It is targeted at application
+ developers who wish to use JBoss Cache in their codebase, as well as "OEM" developers who wish to build on and
+ extend JBoss Cache features. As such, this book is split into two major sections - one detailing the "User" API
+ and the other going much deeper into specialist topics and the JBoss Cache architecture.
</para>
<para>
In general, a good knowledge of the Java programming language along with a strong appreciation and understanding
- of transactions and concurrent threads is necessary. No prior knowledge of JBoss Application Server is expected
+ of transactions and concurrent programming is necessary. No prior knowledge of JBoss Application Server is expected
or required.
</para>
@@ -31,10 +31,10 @@
<ulink url="http://jboss.org/index.html?module=bb&op=main&c=29">user forum</ulink>
linked on the JBoss Cache <ulink url="http://labs.jboss.com/jbosscache">website.</ulink> We also provide a mechanism for
tracking bug reports and feature requests on the JBoss Cache <ulink url="http://jira.jboss.com/jira/browse/JBCACHE">JIRA issue tracker.</ulink>
-
+ </para>
+ <para>
If you are interested in the development of JBoss Cache or in translating this documentation into other languages,
- we'd love
- to hear from you. Please post a message on the
+ we'd love to hear from you. Please post a message on the
<ulink url="http://jboss.org/index.html?module=bb&op=main&c=29">user forum</ulink>
or contact us by using the JBoss Cache <ulink url="https://lists.jboss.org/mailman/listinfo/jbosscache-dev">developer mailing list.</ulink>
</para>
@@ -45,4 +45,8 @@
of JBoss Cache you intend to use.
</para>
+ <para>
+ Happy reading!
+ </para>
+
</preface>
\ No newline at end of file
More information about the jbosscache-commits
mailing list