[jboss-cvs] JBossCache/docs/JBossCache-UserGuide/en/modules ...
Manik Surtani
msurtani at jboss.com
Mon Jan 29 21:06:03 EST 2007
User: msurtani
Date: 07/01/29 21:06:03
Modified: docs/JBossCache-UserGuide/en/modules preface.xml
configuration.xml eviction_policies.xml
architecture.xml replication.xml
configuration_reference.xml compatibility.xml
cache_loaders.xml introduction.xml basic_api.xml
transactions.xml
Log:
More doc updates
Revision Changes Path
1.7 +2 -2 JBossCache/docs/JBossCache-UserGuide/en/modules/preface.xml
(In the diff below, changes in quantity of whitespace are not shown.)
Index: preface.xml
===================================================================
RCS file: /cvsroot/jboss/JBossCache/docs/JBossCache-UserGuide/en/modules/preface.xml,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -b -r1.6 -r1.7
--- preface.xml 29 Jan 2007 17:40:35 -0000 1.6
+++ preface.xml 30 Jan 2007 02:06:03 -0000 1.7
@@ -2,11 +2,11 @@
<title>Preface</title>
<para>
- This is the official JBoss Cache user guide. Along with it's accompanying documents (an FAQ, a tutorial and a
+ 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>
</para>
<para>
- When used, JBoss Cache refers to JBoss Cache Core, a tree-structured clustered, transactional cache.
+ 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.)
1.7 +1 -1 JBossCache/docs/JBossCache-UserGuide/en/modules/configuration.xml
(In the diff below, changes in quantity of whitespace are not shown.)
Index: configuration.xml
===================================================================
RCS file: /cvsroot/jboss/JBossCache/docs/JBossCache-UserGuide/en/modules/configuration.xml,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -b -r1.6 -r1.7
--- configuration.xml 29 Jan 2007 17:40:35 -0000 1.6
+++ configuration.xml 30 Jan 2007 02:06:03 -0000 1.7
@@ -25,7 +25,7 @@
In addition to the XML-based configuration above, a programmatic configuration option is available.
<literal>org.jboss.cache.config.Configuration</literal>
is central to configuring JBoss Cache programmatically,
- and an instance is is created, configured and passed in to a
+ and an instance is created, configured and passed in to a
<literal>org.jboss.cache.CacheFactory</literal>
to
create a cache.
1.7 +2 -2 JBossCache/docs/JBossCache-UserGuide/en/modules/eviction_policies.xml
(In the diff below, changes in quantity of whitespace are not shown.)
Index: eviction_policies.xml
===================================================================
RCS file: /cvsroot/jboss/JBossCache/docs/JBossCache-UserGuide/en/modules/eviction_policies.xml,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -b -r1.6 -r1.7
--- eviction_policies.xml 29 Jan 2007 17:40:35 -0000 1.6
+++ eviction_policies.xml 30 Jan 2007 02:06:03 -0000 1.7
@@ -52,7 +52,7 @@
<itemizedlist>
<listitem><literal>wakeUpIntervalSeconds</literal> - this required parameter defines how often the eviction thread runs</listitem>
- <listitem><literal>eventQueueSize</literal> - this optional parameter defines how large a queue of items to evict to create. If your eviction thread does not run often enough, you may need to increase this.</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.</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>
@@ -104,7 +104,7 @@
<itemizedlist>
<listitem><literal>maxNodes</literal> - This is the maximum number of nodes allowed in this region. 0 denotes no limit.</listitem>
<listitem>
- <literal>timeToLiveSeconds</literal> - Time to idle (in seconds) before the node is swept away. 0 denotes no limit.
+ <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.
</listitem>
<listitem>
1.6 +8 -10 JBossCache/docs/JBossCache-UserGuide/en/modules/architecture.xml
(In the diff below, changes in quantity of whitespace are not shown.)
Index: architecture.xml
===================================================================
RCS file: /cvsroot/jboss/JBossCache/docs/JBossCache-UserGuide/en/modules/architecture.xml,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -b -r1.5 -r1.6
--- architecture.xml 29 Jan 2007 17:40:35 -0000 1.5
+++ architecture.xml 30 Jan 2007 02:06:03 -0000 1.6
@@ -1,7 +1,7 @@
<chapter id="architecture">
<title>Architecture</title>
<section id="architecture.tree_structure">
- <title>How Your Data Is Organised</title>
+ <title>Data Structures Within The Cache</title>
<para>
@@ -75,7 +75,7 @@
</section>
<section id="architecture.invocations">
- <title>How Calls Are Invoked On The Data Structure</title>
+ <title>Method Invocations On Nodes</title>
<para>
Since the cache is essentially a collection of nodes, aspects such as clustering, persistence, eviction, etc.
need to be applied to these nodes when operations are invoked on the cache as a whole or on individual nodes.
@@ -145,17 +145,15 @@
<section id="architecture.invocationcontext">
<title>InvocationContexts</title>
<para>
- This context is one that holds intermediate state for the duration of a single invocation, and is set up and
+ <literal>InvocationContext</literal> 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.
</para>
<para>
- The purpose of the <literal>InvocationContext</literal> is to hold information about a call, such as
- any <literal>javax.transaction.Transaction</literal> or <literal>org.jboss.cache.transaction.GlobalTransaction</literal>
- objects associated with a call, including invocation information such as <literal>InvocationContext.isOriginLocal()</literal>.
- </para>
- <para>
- The <literal>InvocationContext</literal> is also where <literal>Option</literal> objects can be added to specify
- single-invocation configuration overrides. More about this subject in the <link linkend="configuration.options">configuration chapter</link>.
+ <literal>InvocationContext</literal>, as its name implies, holds contextual information associated with a single cache
+ method invocation. Contextual information includes associated
+ <literal>javax.transaction.Transaction</literal> or <literal>org.jboss.cache.transaction.GlobalTransaction</literal>,
+ method invocation origin (<literal>InvocationContext.isOriginLocal()</literal>) as well as <link
+ linkend="configuration.options"><literal>Option</literal> overrides</link>.
</para>
<para>
The <literal>InvocationContext</literal> can be obtained by calling <literal>Cache.getInvocationContext()</literal>.
1.8 +1 -1 JBossCache/docs/JBossCache-UserGuide/en/modules/replication.xml
(In the diff below, changes in quantity of whitespace are not shown.)
Index: replication.xml
===================================================================
RCS file: /cvsroot/jboss/JBossCache/docs/JBossCache-UserGuide/en/modules/replication.xml,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -b -r1.7 -r1.8
--- replication.xml 29 Jan 2007 17:40:35 -0000 1.7
+++ replication.xml 30 Jan 2007 02:06:03 -0000 1.8
@@ -56,7 +56,7 @@
<para>When using transactions, replication only occurs at the
transaction boundary - i.e., when a transaction commits. This results
- in minimising replication traffic since a single modification os
+ in minimising replication traffic since a single modification is
broadcast rather than a series of individual modifications, and can be
a lot more efficient than not using transactions. Another effect of
this is that if a transaction were to roll back, nothing is broadcast
1.6 +2 -2 JBossCache/docs/JBossCache-UserGuide/en/modules/configuration_reference.xml
(In the diff below, changes in quantity of whitespace are not shown.)
Index: configuration_reference.xml
===================================================================
RCS file: /cvsroot/jboss/JBossCache/docs/JBossCache-UserGuide/en/modules/configuration_reference.xml,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -b -r1.5 -r1.6
--- configuration_reference.xml 29 Jan 2007 17:40:35 -0000 1.5
+++ configuration_reference.xml 30 Jan 2007 02:06:03 -0000 1.6
@@ -421,7 +421,7 @@
<entry>
<para>Time in milliseconds for elements from the replication
- queue to be replicated.
+ queue to be replicated. Only used if <literal>UseReplQueue</literal> is enabled.
</para>
</entry>
</row>
@@ -433,7 +433,7 @@
<entry>
<para>Max number of elements in the replication queue until
- replication kicks in.
+ replication kicks in. Only used if <literal>UseReplQueue</literal> is enabled.
</para>
</entry>
</row>
1.3 +8 -0 JBossCache/docs/JBossCache-UserGuide/en/modules/compatibility.xml
(In the diff below, changes in quantity of whitespace are not shown.)
Index: compatibility.xml
===================================================================
RCS file: /cvsroot/jboss/JBossCache/docs/JBossCache-UserGuide/en/modules/compatibility.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -b -r1.2 -r1.3
--- compatibility.xml 23 Jan 2007 15:23:23 -0000 1.2
+++ compatibility.xml 30 Jan 2007 02:06:03 -0000 1.3
@@ -26,4 +26,12 @@
still providing a means to preserve interoperability.
</para>
+ <section>
+ <title>Compatibility Matrix</title>
+ <para>
+ A <ulink url="http://labs.jboss.com/portal/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.
+ </para>
+ </section>
+
</chapter>
\ No newline at end of file
1.8 +37 -43 JBossCache/docs/JBossCache-UserGuide/en/modules/cache_loaders.xml
(In the diff below, changes in quantity of whitespace are not shown.)
Index: cache_loaders.xml
===================================================================
RCS file: /cvsroot/jboss/JBossCache/docs/JBossCache-UserGuide/en/modules/cache_loaders.xml,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -b -r1.7 -r1.8
--- cache_loaders.xml 29 Jan 2007 17:40:35 -0000 1.7
+++ cache_loaders.xml 30 Jan 2007 02:06:03 -0000 1.8
@@ -64,7 +64,7 @@
could establish a connection to the database.
</para>
- <para>The CacheLoader interface has a set of methods that are called
+ <para>The <literal>CacheLoader</literal> interface has a set of methods that are called
when no transactions are used:
<literal>get()</literal>
,
@@ -95,7 +95,7 @@
elements, which represent the changes
made to a cache for a given transaction. When
<literal>prepare()</literal>
- returns successfully, then the CacheLoader
+ returns successfully, then the cache loader
<emphasis>must</emphasis>
be able to commit (or rollback) the
transaction successfully.
@@ -103,31 +103,21 @@
<para>
JBoss Cache takes care of calling prepare(), commit()
- and rollback() on the CacheLoaders at the right time.
+ and rollback() on the cache loaders at the right time.
</para>
<para>The
<literal>commit()</literal>
- method tells the CacheLoader to
+ method tells the cache loader to
commit the transaction, and the
<literal>rollback()</literal>
method
- tells the CacheLoader to discard the changes associated with that
+ tells the cache loader to discard the changes associated with that
transaction.
</para>
- <para>The last two methods are
- <literal>loadEntireState()</literal>
- and
- <literal>storeEntireState()</literal>
- . The first method asks the
- CacheLoader to get the entire state the backend store manages and return
- it as a byte buffer, and the second tells a CacheLoader to replace its
- entire state with the byte buffer argument. These methods are used for
- scenarios where each JBossCache node in a cluster has its own local data
- store, e.g. a local DB, and - when a new node starts - we have to
- initialize its backend store with the contents of the backend store of
- an existing member. See below for deails.
+ <para>See the javadocs on this interface for a detailed explanation on each method and the contract implementations
+ would need to fulfil.
</para>
</section>
@@ -166,7 +156,7 @@
<class>org.jboss.cache.loader.JDBCCacheLoader</class>
- <!-- properties to ass in to the cache loader -->
+ <!-- properties to pass in to the cache loader -->
<properties>
cache.jdbc.driver=com.mysql.jdbc.Driver
cache.jdbc.url=jdbc:mysql://localhost:3306/jbossdb
@@ -203,10 +193,10 @@
<para>The
<literal>CacheLoaderClass</literal>
attribute defines the
- class of the CacheLoader implementation. (Note that, because of a bug in
+ class of the cache loader implementation. (Note that, because of a bug in
the properties editor in JBoss AS, backslashes in variables for Windows
filenames might not get expanded correctly, so replace="false" may be
- necessary). Note that an implementation of CacheLoader has to have an empty
+ necessary). Note that an implementation of cache loader has to have an empty
constructor.
</para>
@@ -217,7 +207,7 @@
implementation for example defines the root directory to be used,
whereas a database implementation might define the database URL, name
and password to establish a database connection. This configuration is
- passed to the CacheLoader implementation via
+ passed to the cache loader implementation via
<literal>CacheLoader.setConfig(Properties)</literal>. Note that
backspaces may have to be escaped.
</para>
@@ -293,9 +283,9 @@
methods are pushed down to the specific cache loader. Situations may
arise where transient application data should only reside in a file
based cache loader on the same server as the in-memory cache, for
- example, with a further shared JDBC cache loader used by all servers in
+ example, with a further shared <literal>JDBCCacheLoader</literal> used by all servers in
the network. This feature allows you to write to the 'local' file cache
- loader but not the shared JDBC cache loader. This property defaults to
+ loader but not the shared <literal>JDBCCacheLoader</literal>. This property defaults to
<literal>false</literal>
, so writes are propagated to all cache loaders
configured.
@@ -380,12 +370,12 @@
<para>The currently available implementations shipped with JBoss Cache are as follows.</para>
<section>
- <title>File system based CacheLoaders</title>
+ <title>File system based cache loaders</title>
<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> configuration element
contains a <literal>location</literal> property, which maps to a directory to be used as a persistent store.
- (e.g., <literal>location=/tmp/myDataStore</literal>).
+ (e.g., <literal>location=/tmp/myDataStore</literal>). Used mainly for testing and not recommended for production use.
</para>
<itemizedlist>
<listitem>
@@ -403,7 +393,7 @@
<listitem>
<para>
<literal>BdbjeCacheLoader</literal>
- , which is a CacheLoader implementation based on the Oracle/Sleepycat's
+ , which is a cache loader implementation based on the Oracle/Sleepycat's
<ulink url="http://www.oracle.com/database/berkeley-db/index.html">BerkeleyDB Java Edition</ulink>.
</para>
</listitem>
@@ -411,7 +401,7 @@
<listitem>
<para>
<literal>JdbmCacheLoader</literal>
- , which is a CacheLoader
+ , which is a cache loader
implementation based on the <ulink url="http://jdbm.sourceforge.net/">JDBM engine</ulink>, a fast and free alternative to
BerkeleyDB.
</para>
@@ -462,7 +452,7 @@
<section id="cl.jdbc">
<title>JDBCCacheLoader</title>
- <para>JBossCache is distributed with a JDBC-based CacheLoader
+ <para>JBossCache is distributed with a JDBC-based cache loader
implementation that stores/loads nodes' state into a relational database.
The implementing class is
<literal>org.jboss.cache.loader.JDBCCacheLoader</literal>
@@ -489,7 +479,7 @@
<emphasis>WARNING:</emphasis>
JBoss Cache does not impose any
limitations on the types of objects used in <literal>Fqn</literal> but this implementation of
- CacheLoader requires <literal>Fqn</literal> to contain only objects of type
+ cache loader requires <literal>Fqn</literal> to contain only objects of type
<literal>java.lang.String</literal>
. Another limitation for <literal>Fqn</literal> is its
length. Since <literal>Fqn</literal> is a primary key, its default column type is
@@ -658,7 +648,7 @@
<section>
<title>Configuration example</title>
- <para>Below is an example of a JDBC CacheLoader using Oracle as
+ <para>Below is an example of a JDBCCacheLoader using Oracle as
database. The CacheLoaderConfiguration XML element contains an
arbitrary set of properties which define the database-related
configuration.
@@ -830,7 +820,7 @@
</para>
<para>To alleviate single point of failure, we could configure several cache loaders.
- The first CacheLoader is a ClusteredCacheLoader, the second a TcpDelegatingCacheLoader, and the
+ The first cache loader is a ClusteredCacheLoader, the second a TcpDelegatingCacheLoader, and the
last a JDBCacheLoader, effectively defining our cost of access to a
cache in increasing order.
</para>
@@ -843,7 +833,7 @@
<section id="cl.pass">
<title>Cache Passivation</title>
- <para>A CacheLoader can be used to enforce node passivation and
+ <para>A cache loader can be used to enforce node passivation and
activation on eviction in a cache.
</para>
@@ -857,7 +847,7 @@
</emphasis>
is the process of restoring an object from the
data store into the in-memory cache when it's needed to be used. In both
- cases, the configured CacheLoader will be used to read from the data
+ cases, the configured cache loader will be used to read from the data
store and write to the data store.
</para>
@@ -882,6 +872,10 @@
<section>
<title>Strategies</title>
+ <para>
+ This section discusses different patterns of combining different cache loader types and configuration
+ options to achieve specific outcomes.
+ </para>
<section>
<title>Local Cache With Store</title>
@@ -890,7 +884,7 @@
cache mode is
<literal>LOCAL</literal>
, therefore no replication is going
- on. The CacheLoader simply loads non-existing elements from the store
+ on. The cache loader simply loads non-existing elements from the store
and stores modifications back to the store. When the cache is started,
depending on the
<literal>preload</literal>
@@ -916,7 +910,7 @@
</mediaobject>
</figure>
- <para>Both nodes have a CacheLoader that accesses a common shared
+ <para>Both nodes have a cache loader that accesses a common shared
backend store. This could for example be a shared filesystem (using
the FileCacheLoader), or a shared database. Because both nodes access
the same store, they don't necessarily need state transfer on
@@ -937,8 +931,8 @@
<para>When storing a value, the writer takes care of storing the
change in the backend store. For example, if node1 made change C1 and
- node2 C2, then node1 would tell its CacheLoader to store C1, and node2
- would tell its CacheLoader to store C2.
+ node2 C2, then node1 would tell its cache loader to store C1, and node2
+ would tell its cache loader to store C2.
</para>
</section>
@@ -957,11 +951,11 @@
<para>This is a similar case as the previous one, but here only one
node in the cluster interacts with a backend store via its
- CacheLoader. All other nodes perform in-memory replication. A use case
+ cache loader. All other nodes perform in-memory replication. A use case
for this is HTTP session replication, where all nodes replicate
sessions in-memory, and - in addition - one node saves the sessions to
a persistent backend store. Note that here it may make sense for the
- CacheLoader to store changes asynchronously, that is
+ cache loader to store changes asynchronously, that is
<emphasis>not</emphasis>
on the caller's thread, in order not to slow
down the cluster by accessing (for example) a database. This is a
@@ -984,7 +978,7 @@
<para>Here, each node has its own datastore. Modifications to the
cache are (a) replicated across the cluster and (b) persisted using
- the CacheLoader. This means that all datastores have exactly the same
+ the cache loader. This means that all datastores have exactly the same
state. When replicating changes synchronously and in a transaction,
the two phase commit protocol takes care that all modifications are
replicated and persisted in each datastore, or none is replicated and
@@ -1016,7 +1010,7 @@
</listitem>
<listitem>
- <para>Then the coordinator asks its CacheLoader for the entire
+ <para>Then the coordinator asks its cache loader for the entire
state using
<literal>loadEntireState()</literal>
. It then sends
@@ -1025,7 +1019,7 @@
</listitem>
<listitem>
- <para>The new node then tells its CacheLoader to store that state
+ <para>The new node then tells its cache loader to store that state
in its store, overwriting the old state. This is the
<literal>CacheLoader.storeEntireState()</literal>
method
@@ -1042,7 +1036,7 @@
<para>The new node now has the same state in its backend store as
everyone else in the cluster, and modifications received from
other nodes will now be persisted using the local
- CacheLoader.
+ cache loader.
</para>
</listitem>
</orderedlist>
1.6 +3 -3 JBossCache/docs/JBossCache-UserGuide/en/modules/introduction.xml
(In the diff below, changes in quantity of whitespace are not shown.)
Index: introduction.xml
===================================================================
RCS file: /cvsroot/jboss/JBossCache/docs/JBossCache-UserGuide/en/modules/introduction.xml,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -b -r1.5 -r1.6
--- introduction.xml 29 Jan 2007 17:40:35 -0000 1.5
+++ introduction.xml 30 Jan 2007 02:06:03 -0000 1.6
@@ -22,7 +22,7 @@
<para>
Pojo Cache is an extension of the core JBoss Cache API. Pojo Cache offers additional functionality such as:
<itemizedlist>
- <listitem>maintaining object references even affter replication or persistence.</listitem>
+ <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>
</itemizedlist>
@@ -72,7 +72,7 @@
</para>
<para>When a change is made to an object in the cache and that change is done in
- the context of a transaction, then we defer the replication of changes until the transaction
+ the context of a transaction, the replication of changes is deferred until the transaction
commits successfully. All modifications are kept in a list associated with
the transaction for the caller. When the transaction commits, we replicate the
changes. Otherwise, (on a rollback) we simply undo the changes locally
@@ -98,7 +98,7 @@
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.
- More on concurrency, locking and isolation levels later.
+ Concurrency, locking and isolation levels will be discussed later.
</para>
</section>
1.6 +23 -15 JBossCache/docs/JBossCache-UserGuide/en/modules/basic_api.xml
(In the diff below, changes in quantity of whitespace are not shown.)
Index: basic_api.xml
===================================================================
RCS file: /cvsroot/jboss/JBossCache/docs/JBossCache-UserGuide/en/modules/basic_api.xml,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -b -r1.5 -r1.6
--- basic_api.xml 29 Jan 2007 17:40:35 -0000 1.5
+++ basic_api.xml 30 Jan 2007 02:06:03 -0000 1.6
@@ -3,12 +3,6 @@
<section>
<title>API Classes</title>
<para>
- <mediaobject>
- <imageobject>
- <imagedata fileref="images/PublicAPI.png" format="PNG"/>
- </imageobject>
- </mediaobject>
-
The
<literal>Cache</literal>
interface is the primary mechanism for interacting with JBoss Cache. It is
@@ -26,6 +20,13 @@
, you can use it to look up
<literal>Node</literal>
objects in the tree structure, and store data in the tree.
+
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="images/PublicAPI.png" format="PNG"/>
+ </imageobject>
+ </mediaobject>
+
</para>
</section>
<section>
@@ -122,17 +123,21 @@
Adding a CacheListener
</title>
<para>
- <mediaobject>
- <imageobject>
- <imagedata fileref="images/Listeners.png" format="PNG"/>
- </imageobject>
- </mediaobject>
+
The
<literal>org.jboss.cache.CacheListener</literal>
interface is a convenient mechanism for receiving notifications from a Cache
about events that happen in the Cache. The interface may be implemented directly, or as a convenience,
<literal>org.jboss.cache.AbstractCacheListener</literal>
can be extended.
+
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="images/Listeners.png" format="PNG"/>
+ </imageobject>
+ </mediaobject>
+
+
<literal>AbstractCacheListener</literal>
implements all the methods in
<literal>CacheListener</literal>
@@ -153,21 +158,24 @@
assertTrue(cache.getCacheListeners().contains(myListener));
</programlisting>
+
+ Refer to the javadocs on the <literal>CacheLoader</literal> interface for details on the parameters passed in
+ to each of the callback methods.
</para>
</section>
<section>
<title>Using Cache Loaders</title>
<para>
- CacheLoaders are an important part of JBoss Cache. They allow persistence of nodes to disk or to remote cache
- clusters, and allow for passivation when caches run out of memory. In addition, CacheLoaders allow JBoss Cache
+ Cache loaders are an important part of JBoss Cache. They allow persistence of nodes to disk or to remote cache
+ clusters, and allow for passivation when caches run out of memory. In addition, cache loaders allow JBoss Cache
to perform 'warm starts', where in-memory state can be preloaded from persistent storage. JBoss Cache ships
- with a number of CacheLoader implementations.
+ with a number of cache loader implementations.
<itemizedlist>
<listitem>
<literal>org.jboss.cache.loader.FileCacheLoader</literal>
- a basic, filesystem based cache loader that persists data to disk. Non-transactional and not very
- performant, but a very simple solution.
+ performant, but a very simple solution. Used mainly for testing and not recommended for production use.
</listitem>
<listitem>
<literal>org.jboss.cache.loader.JDBCCacheLoader</literal>
1.5 +1 -1 JBossCache/docs/JBossCache-UserGuide/en/modules/transactions.xml
(In the diff below, changes in quantity of whitespace are not shown.)
Index: transactions.xml
===================================================================
RCS file: /cvsroot/jboss/JBossCache/docs/JBossCache-UserGuide/en/modules/transactions.xml,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -b -r1.4 -r1.5
--- transactions.xml 29 Jan 2007 17:40:35 -0000 1.4
+++ transactions.xml 30 Jan 2007 02:06:03 -0000 1.5
@@ -194,7 +194,7 @@
Optimistic locking makes use of the <literal>DataVersion</literal> interface (and an internal and default
<literal>DefaultDataVersion</literal> implementation to keep a track of node versioning. In certain cases,
where cached data is an in-memory representation of data from an external source such as a database,
- it makes sense to aling the versions used in JBoss Cache with the versions used externally. As such,
+ it makes sense to align the versions used in JBoss Cache with the versions used externally. As such,
using the <link linkend="configuration.options">options API</link>, it is possible to set the <literal>DataVersion</literal>
you wish to use on a per-invocation basis, allowing you to implement the <literal>DataVersion</literal>
interface to hold the versioning information obtained externally before putting your data into the
More information about the jboss-cvs-commits
mailing list