You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jcs-dev@jakarta.apache.org by as...@apache.org on 2006/07/14 19:44:36 UTC
svn commit: r421961 - in /jakarta/jcs/trunk/xdocs:
MySQLDiskCacheProperties.xml RemoteAuxCache.xml navigation.xml
Author: asmuts
Date: Fri Jul 14 10:44:36 2006
New Revision: 421961
URL: http://svn.apache.org/viewvc?rev=421961&view=rev
Log:
adding an xdoc describing two new mysql disk cache configuration options
Added:
jakarta/jcs/trunk/xdocs/MySQLDiskCacheProperties.xml
Modified:
jakarta/jcs/trunk/xdocs/RemoteAuxCache.xml
jakarta/jcs/trunk/xdocs/navigation.xml
Added: jakarta/jcs/trunk/xdocs/MySQLDiskCacheProperties.xml
URL: http://svn.apache.org/viewvc/jakarta/jcs/trunk/xdocs/MySQLDiskCacheProperties.xml?rev=421961&view=auto
==============================================================================
--- jakarta/jcs/trunk/xdocs/MySQLDiskCacheProperties.xml (added)
+++ jakarta/jcs/trunk/xdocs/MySQLDiskCacheProperties.xml Fri Jul 14 10:44:36 2006
@@ -0,0 +1,177 @@
+<?xml version="1.0"?>
+
+<document>
+ <properties>
+ <title>MySQL Disk Cache Configuration</title>
+ <author email="asmuts@apache.org">Aaron Smuts</author>
+ </properties>
+
+ <body>
+ <section name="MySQL Disk Auxiliary Cache Configuration">
+
+ <p>
+ The MySQL Disk Cache uses all of the JDBC Disk Cache
+ properties. It adds a few of its own. The following
+ properties on apply to the MySQL Disk Cache plugin.
+ </p>
+
+ <subsection name="MySQL Disk Configuration Properties">
+ <table>
+ <tr>
+ <th>Property</th>
+ <th>Description</th>
+ <th>Required</th>
+ <th>Default Value</th>
+ </tr>
+ <tr>
+ <td>optimizationSchedule</td>
+ <td>
+ For now this is a simple comma delimited
+ list of HH:MM:SS times to optimize the
+ table. If none is supplied, then no
+ optimizations will be performed.
+
+ In the future we can add a chron like
+ scheduling system. This was created to meet
+ a pressing need to optimize fragmented
+ MyISAM tables. When the table becomes
+ fragmented, it starts to take a long time to
+ run the shrinker that deletes expired
+ elements.
+
+ Setting the value to "03:01,15:00" will
+ cause the optimizer to run at 3 am and at 3
+ pm.
+ </td>
+ <td>N</td>
+ <td>null</td>
+ </tr>
+
+ <tr>
+ <td>balkDuringOptimization</td>
+ <td>
+ If this is true, then when JCS is optimizing
+ the table it will return null from get
+ requests and do nothing for put requests.
+
+ If you are using the remote cache and have a
+ failover server configured in a remote cache
+ cluster, and you allow clustered gets, the
+ primary server will act as a proxy to the
+ failover. This way, optimization should have
+ no impact for clients of the remote cache.
+ </td>
+ <td>N</td>
+ <td>true</td>
+ </tr>
+
+ </table>
+ </subsection>
+
+ <subsection name="Example Configuration">
+ <source>
+ <![CDATA[
+##############################################################
+################## AUXILIARY CACHES AVAILABLE ################
+# MYSQL disk cache
+jcs.auxiliary.MYSQL=org.apache.jcs.auxiliary.disk.jdbc.mysql.MySQLDiskCacheFactory
+jcs.auxiliary.MYSQL.attributes=org.apache.jcs.auxiliary.disk.jdbc.mysql.MySQLDiskCacheAttributes
+jcs.auxiliary.MYSQL.attributes.userName=sa
+jcs.auxiliary.MYSQL.attributes.password=
+jcs.auxiliary.MYSQL.attributes.url=jdbc:hsqldb:target/cache_hsql_db
+jcs.auxiliary.MYSQL.attributes.driverClassName=org.hsqldb.jdbcDriver
+jcs.auxiliary.MYSQL.attributes.tableName=JCS_STORE_MYSQL
+jcs.auxiliary.MYSQL.attributes.testBeforeInsert=false
+jcs.auxiliary.MYSQL.attributes.maxActive=15
+jcs.auxiliary.MYSQL.attributes.allowRemoveAll=true
+jcs.auxiliary.MYSQL.attributes.MaxPurgatorySize=10000000
+jcs.auxiliary.MYSQL.attributes.optimizationSchedule=12:34:56,02:34:54
+jcs.auxiliary.MYSQL.attributes.balkDuringOptimization=true
+ ]]>
+ </source>
+ </subsection>
+
+ <subsection name="MySQL Disk Event Queue Configuration">
+
+ <table>
+ <tr>
+ <th>Property</th>
+ <th>Description</th>
+ <th>Required</th>
+ <th>Default Value</th>
+ </tr>
+ <tr>
+ <td>EventQueueType</td>
+ <td>
+ This should be either SINGLE or POOLED. By
+ default the single style pool is used. The
+ single style pool uses a single thread per
+ event queue. That thread is killed whenever
+ the queue is inactive for 30 seconds. Since
+ the disk cache uses an event queue for every
+ region, if you have many regions and they
+ are all active, you will be using many
+ threads. To limit the number of threads, you
+ can configure the disk cache to use the
+ pooled event queue. Using more threads than
+ regions will not add any benefit for the
+ indexed disk cache, since only one thread
+ can read or write at a time for a single
+ region.
+ </td>
+ <td>N</td>
+ <td>SINGLE</td>
+ </tr>
+ <tr>
+ <td>EventQueuePoolName</td>
+ <td>
+ This is the name of the pool to use. It is
+ required if you choose the POOLED event
+ queue type, otherwise it is ignored.
+ </td>
+ <td>Y</td>
+ <td>n/a</td>
+ </tr>
+ </table>
+ </subsection>
+
+ <subsection
+ name="Example Configuration Using Thread Pool">
+ <source>
+ <![CDATA[
+##############################################################
+################## AUXILIARY CACHES AVAILABLE ################
+# MYSQL disk cache
+jcs.auxiliary.MYSQL=org.apache.jcs.auxiliary.disk.jdbc.mysql.MySQLDiskCacheFactory
+jcs.auxiliary.MYSQL.attributes=org.apache.jcs.auxiliary.disk.jdbc.mysql.MySQLDiskCacheAttributes
+jcs.auxiliary.MYSQL.attributes.userName=sa
+jcs.auxiliary.MYSQL.attributes.password=
+jcs.auxiliary.MYSQL.attributes.url=jdbc:hsqldb:target/cache_hsql_db
+jcs.auxiliary.MYSQL.attributes.driverClassName=org.hsqldb.jdbcDriver
+jcs.auxiliary.MYSQL.attributes.tableName=JCS_STORE_MYSQL
+jcs.auxiliary.MYSQL.attributes.testBeforeInsert=false
+jcs.auxiliary.MYSQL.attributes.maxActive=15
+jcs.auxiliary.MYSQL.attributes.allowRemoveAll=true
+jcs.auxiliary.MYSQL.attributes.MaxPurgatorySize=10000000
+jcs.auxiliary.MYSQL.attributes.optimizationSchedule=12:34:56,02:34:54
+jcs.auxiliary.MYSQL.attributes.balkDuringOptimization=true
+jcs.auxiliary.MYSQL.attributes.EventQueueType=POOLED
+jcs.auxiliary.MYSQL.attributes.EventQueuePoolName=disk_cache_event_queue
+
+##############################################################
+################## OPTIONAL THREAD POOL CONFIGURATION #########
+# Disk Cache pool
+thread_pool.disk_cache_event_queue.useBoundary=false
+thread_pool.disk_cache_event_queue.boundarySize=500
+thread_pool.disk_cache_event_queue.maximumPoolSize=15
+thread_pool.disk_cache_event_queue.minimumPoolSize=10
+thread_pool.disk_cache_event_queue.keepAliveTime=3500
+thread_pool.disk_cache_event_queue.whenBlockedPolicy=RUN
+thread_pool.disk_cache_event_queue.startUpSize=10
+ ]]>
+ </source>
+ </subsection>
+
+ </section>
+ </body>
+</document>
\ No newline at end of file
Modified: jakarta/jcs/trunk/xdocs/RemoteAuxCache.xml
URL: http://svn.apache.org/viewvc/jakarta/jcs/trunk/xdocs/RemoteAuxCache.xml?rev=421961&r1=421960&r2=421961&view=diff
==============================================================================
--- jakarta/jcs/trunk/xdocs/RemoteAuxCache.xml (original)
+++ jakarta/jcs/trunk/xdocs/RemoteAuxCache.xml Fri Jul 14 10:44:36 2006
@@ -1,113 +1,135 @@
<?xml version="1.0"?>
<document>
- <properties>
- <title>Remote Auxiliary Cache Client / Server</title>
- <author email="pete@kazmier.com">Pete Kazmier</author>
- <author email="ASmuts@apache.org">Aaron Smuts</author>
- </properties>
+ <properties>
+ <title>Remote Auxiliary Cache Client / Server</title>
+ <author email="pete@kazmier.com">Pete Kazmier</author>
+ <author email="ASmuts@apache.org">Aaron Smuts</author>
+ </properties>
- <body>
- <section name="Remote Auxiliary Cache Client / Server">
- <p>
- The Remote Auxiliary Cache is an optional plug in for JCS. It
- is intended for use in multi-tiered systems to maintain cache
- consistency. It uses a highly reliable RMI client server
- framework that currently allows for any number of clients. Using a
- listener id allows multiple clients running on the same machine
- to connect to the remote cache server. All cache regions on one
- client share a listener per auxiliary, but register separately.
- This minimizes the number of connections necessary and still
- avoids unnecessary updates for regions that are not configured
- to use the remote cache.
- </p>
- <p>
- Local remote cache clients connect to the remote cache on a
- configurable port and register a listener to receive cache
- update callbacks at a configurable port.
- </p>
- <p>
- If there is an error connecting to the remote server or if an
- error occurs in transmission, the client will retry for a
- configurable number of tires before moving into a
- failover-recovery mode. If failover servers are configured the
- remote cache clients will try to register with other failover
- servers in a sequential order. If a connection is made, the
- client will broadcast all relevant cache updates to the failover
- server while trying periodically to reconnect with the primary
- server. If there are no failovers configured the client will
- move into a zombie mode while it tries to re-establish the
- connection. By default, the cache clients run in an optimistic
- mode and the failure of the communication channel is detected by
- an attempted update to the server. A pessimistic mode is
- configurable so that the clients will engage in active status
- checks.
- </p>
- <p>
- The remote cache server broadcasts updates to listeners other
- than the originating source. If the remote cache fails to
- propagate an update to a client, it will retry for a
- configurable number of tries before de-registering the client.
- </p>
- <p>
- The cache hub communicates with a facade that implements a
- zombie pattern (balking facade) to prevent blocking. Puts and
- removals are queued and occur asynchronously in the background.
- Get requests are synchronous and can potentially block if there
- is a communication problem.
- </p>
- <p>
- By default client updates are light weight. The client
- listeners are configured to remove elements form the local cache
- when there is a put order from the remote. This allows the
- client memory store to control the memory size algorithm from
- local usage, rather than having the usage patterns dictated by
- the usage patterns in the system at large.
- </p>
- <p>
- When using a remote cache the local cache hub will propagate
- elements in regions configured for the remote cache if the
- element attributes specify that the item to be cached can be
- sent remotely. By default there are no remote restrictions on
- elements and the region will dictate the behavior. The order of
- auxiliary requests is dictated by the order in the configuration
- file. The examples are configured to look in memory, then disk,
- then remote caches. Most elements will only be retrieved from
- the remote cache once, when they are not in memory or disk and
- are first requested, or after they have been invalidated.
- </p>
- <subsection name="Client Configuration">
- <p>
- The configuration is fairly straightforward and is done in the
- auxiliary cache section of the <code>cache.ccf</code>
- configuration file. In the example below, I created a Remote
- Auxiliary Cache Client referenced by <code>RFailover</code>.
- </p>
- <p>
- This auxiliary cache will use <code>localhost:1102</code> as
- its primary remote cache server and will attempt to failover
- to <code>localhost:1103</code> if the primary is down.
- </p>
- <p>
- Setting <code>RemoveUponRemotePut</code> to <code>false</code>
- would cause remote puts to be translated into put requests to
- the client region. By default it is <code>true</code>,
- causing remote put requests to be issued as removes at the
- client level. For groups the put request functions slightly
- differently: the item will be removed, since it is no longer
- valid in its current form, but the list of group elements will
- be updated. This way the client can maintain the complete
- list of group elements without the burden of storing all of
- the referenced elements. Session distribution works in this
- half-lazy replication mode.
- </p>
- <p>
- Setting <code>GetOnly</code> to <code>true</code> would cause
- the remote cache client to stop propagating updates to the
- remote server, while continuing to get items from the remote
- store.
- </p>
- <source><![CDATA[
+ <body>
+ <section name="Remote Auxiliary Cache Client / Server">
+ <p>
+ The Remote Auxiliary Cache is an optional plug in for
+ JCS. It is intended for use in multi-tiered systems to
+ maintain cache consistency. It uses a highly reliable
+ RMI client server framework that currently allows for
+ any number of clients. Using a listener id allows
+ multiple clients running on the same machine to connect
+ to the remote cache server. All cache regions on one
+ client share a listener per auxiliary, but register
+ separately. This minimizes the number of connections
+ necessary and still avoids unnecessary updates for
+ regions that are not configured to use the remote cache.
+ </p>
+ <p>
+ Local remote cache clients connect to the remote cache
+ on a configurable port and register a listener to
+ receive cache update callbacks at a configurable port.
+ </p>
+ <p>
+ If there is an error connecting to the remote server or
+ if an error occurs in transmission, the client will
+ retry for a configurable number of tires before moving
+ into a failover-recovery mode. If failover servers are
+ configured the remote cache clients will try to register
+ with other failover servers in a sequential order. If a
+ connection is made, the client will broadcast all
+ relevant cache updates to the failover server while
+ trying periodically to reconnect with the primary
+ server. If there are no failovers configured the client
+ will move into a zombie mode while it tries to
+ re-establish the connection. By default, the cache
+ clients run in an optimistic mode and the failure of the
+ communication channel is detected by an attempted update
+ to the server. A pessimistic mode is configurable so
+ that the clients will engage in active status checks.
+ </p>
+ <p>
+ The remote cache server broadcasts updates to listeners
+ other than the originating source. If the remote cache
+ fails to propagate an update to a client, it will retry
+ for a configurable number of tries before de-registering
+ the client.
+ </p>
+ <p>
+ The cache hub communicates with a facade that implements
+ a zombie pattern (balking facade) to prevent blocking.
+ Puts and removals are queued and occur asynchronously in
+ the background. Get requests are synchronous and can
+ potentially block if there is a communication problem.
+ </p>
+ <p>
+ By default client updates are light weight. The client
+ listeners are configured to remove elements form the
+ local cache when there is a put order from the remote.
+ This allows the client memory store to control the
+ memory size algorithm from local usage, rather than
+ having the usage patterns dictated by the usage patterns
+ in the system at large.
+ </p>
+ <p>
+ When using a remote cache the local cache hub will
+ propagate elements in regions configured for the remote
+ cache if the element attributes specify that the item to
+ be cached can be sent remotely. By default there are no
+ remote restrictions on elements and the region will
+ dictate the behavior. The order of auxiliary requests is
+ dictated by the order in the configuration file. The
+ examples are configured to look in memory, then disk,
+ then remote caches. Most elements will only be retrieved
+ from the remote cache once, when they are not in memory
+ or disk and are first requested, or after they have been
+ invalidated.
+ </p>
+ <subsection name="Client Configuration">
+ <p>
+ The configuration is fairly straightforward and is
+ done in the auxiliary cache section of the
+ <code>cache.ccf</code>
+ configuration file. In the example below, I created
+ a Remote Auxiliary Cache Client referenced by
+ <code>RFailover</code>
+ .
+ </p>
+ <p>
+ This auxiliary cache will use
+ <code>localhost:1102</code>
+ as its primary remote cache server and will attempt
+ to failover to
+ <code>localhost:1103</code>
+ if the primary is down.
+ </p>
+ <p>
+ Setting
+ <code>RemoveUponRemotePut</code>
+ to
+ <code>false</code>
+ would cause remote puts to be translated into put
+ requests to the client region. By default it is
+ <code>true</code>
+ , causing remote put requests to be issued as
+ removes at the client level. For groups the put
+ request functions slightly differently: the item
+ will be removed, since it is no longer valid in its
+ current form, but the list of group elements will be
+ updated. This way the client can maintain the
+ complete list of group elements without the burden
+ of storing all of the referenced elements. Session
+ distribution works in this half-lazy replication
+ mode.
+ </p>
+ <p>
+ Setting
+ <code>GetOnly</code>
+ to
+ <code>true</code>
+ would cause the remote cache client to stop
+ propagating updates to the remote server, while
+ continuing to get items from the remote store.
+ </p>
+ <source>
+ <![CDATA[
# Remote RMI Cache set up to failover
jcs.auxiliary.RFailover=
org.apache.jcs.auxiliary.remote.RemoteCacheFactory
@@ -117,12 +139,14 @@
localhost:1102,localhost:1103
jcs.auxiliary.RC.attributes.RemoveUponRemotePut=true
jcs.auxiliary.RFailover.attributes.GetOnly=false
- ]]></source>
- <p>
- This cache region is setup to use a disk cache and the remote
- cache configured above:
- </p>
- <source><![CDATA[
+ ]]>
+ </source>
+ <p>
+ This cache region is setup to use a disk cache and
+ the remote cache configured above:
+ </p>
+ <source>
+ <![CDATA[
#Regions preconfirgured for caching
jcs.region.testCache1=DC,RFailover
jcs.region.testCache1.cacheattributes=
@@ -130,27 +154,37 @@
jcs.region.testCache1.cacheattributes.MaxObjects=1000
jcs.region.testCache1.cacheattributes.MemoryCacheName=
org.apache.jcs.engine.memory.lru.LRUMemoryCache
- ]]></source>
- </subsection>
- <subsection name="Server Configuration">
- <p>
- The remote cache configuration is growing. For now, the
- configuration is done at the top of the
- <code>remote.cache.ccf</code> file. The
- <code>startRemoteCache</code> script passes the configuration
- file name to the server when it starts up. The configuration
- parameters below will create a remote cache server that
- listens to port <code>1102</code> and performs call backs on
- the <code>remote.cache.service.port</code>, also specified as
- port <code>1102</code>.
- </p>
- <p>
- The tomcat configuration section is evolving. If
- <code>remote.tomcat.on</code> is set to <code>true</code> an
- embedded tomcat server will run within the remote cache,
- allowing the use of management servlets.
- </p>
- <source><![CDATA[
+ ]]>
+ </source>
+ </subsection>
+ <subsection name="Server Configuration">
+ <p>
+ The remote cache configuration is growing. For now,
+ the configuration is done at the top of the
+ <code>remote.cache.ccf</code>
+ file. The
+ <code>startRemoteCache</code>
+ script passes the configuration file name to the
+ server when it starts up. The configuration
+ parameters below will create a remote cache server
+ that listens to port
+ <code>1102</code>
+ and performs call backs on the
+ <code>remote.cache.service.port</code>
+ , also specified as port
+ <code>1102</code>
+ .
+ </p>
+ <p>
+ The tomcat configuration section is evolving. If
+ <code>remote.tomcat.on</code>
+ is set to
+ <code>true</code>
+ an embedded tomcat server will run within the remote
+ cache, allowing the use of management servlets.
+ </p>
+ <source>
+ <![CDATA[
# Registry used to register and provide the
# IRemoteCacheService service.
registry.host=localhost
@@ -159,26 +193,32 @@
remote.cache.service.port=1102
# cluster setting
remote.cluster.LocalClusterConsistency=true
- ]]></source>
- <p>
- Remote servers can be chainied (or clustered). This allows
- gets from local caches to be distributed between multiple
- remote servers. Since gets are the most common operation for
- caches, remote server chaining can help scale a caching solution.
- </p>
- <p>
- The <code>LocalClusterConsistency</code>
- setting tells the remote cache server if it should broadcast
- updates received from other cluster servers to registered
- local caches.
- </p>
- <p>
- To use remote server clustering, the remote cache will have to
- be told what regions to cluster. The configuration below will
- cluster all non-preconfigured regions with
- <code>RCluster1</code>.
- </p>
- <source><![CDATA[
+ ]]>
+ </source>
+ <p>
+ Remote servers can be chainied (or clustered). This
+ allows gets from local caches to be distributed
+ between multiple remote servers. Since gets are the
+ most common operation for caches, remote server
+ chaining can help scale a caching solution.
+ </p>
+ <p>
+ The
+ <code>LocalClusterConsistency</code>
+ setting tells the remote cache server if it should
+ broadcast updates received from other cluster
+ servers to registered local caches.
+ </p>
+ <p>
+ To use remote server clustering, the remote cache
+ will have to be told what regions to cluster. The
+ configuration below will cluster all
+ non-preconfigured regions with
+ <code>RCluster1</code>
+ .
+ </p>
+ <source>
+ <![CDATA[
# sets the default aux value for any non configured caches
jcs.default=DC,RCluster1
jcs.default.cacheattributes=
@@ -193,38 +233,48 @@
jcs.auxiliary.RCluster1.attributes.RemoveUponRemotePut=false
jcs.auxiliary.RCluster1.attributes.ClusterServers=localhost:1103
jcs.auxiliary.RCluster1.attributes.GetOnly=false
- ]]></source>
- <p>
- RCluster1 is configured to talk to
- a remote server at <code>localhost:1103</code>. Additional
- servers can be added in a comma separated list.
- </p>
- <p>
- If we startup another remote server listening to port 1103,
- (ServerB) then we can have that server talk to the server we have
- been configuring, listening at 1102 (ServerA). This would allow us
- to set some local caches to talk to ServerA and some to talk
- to ServerB. The two remote servers will broadcast
- all puts and removes between themselves, and the get requests
- from local caches could be divided. The local caches do not
- need to know anything about the server chaining configuration,
- unless you want to use a standby, or failover server.
- </p>
- <p>
- We could also use ServerB as a hot standby. This can be done in
- two ways. You could have all local caches point to ServerA as
- a primary and ServerB as a secondary. Alternatively, you can
- set ServerA as the primary for some local caches and ServerB for
- the primary for some others.
- </p>
- <p>
- The local cache configuration below uses ServerA as a primary and
- ServerB as a backup. More than one backup can be defined, but
- only one will be used at a time. If the cache is connected
- to any server except the primary, it will try to restore the
- primary connection indefinitely, at 20 second intervals.
- </p>
- <source><![CDATA[
+ ]]>
+ </source>
+ <p>
+ RCluster1 is configured to talk to a remote server
+ at
+ <code>localhost:1103</code>
+ . Additional servers can be added in a comma
+ separated list.
+ </p>
+ <p>
+ If we startup another remote server listening to
+ port 1103, (ServerB) then we can have that server
+ talk to the server we have been configuring,
+ listening at 1102 (ServerA). This would allow us to
+ set some local caches to talk to ServerA and some to
+ talk to ServerB. The two remote servers will
+ broadcast all puts and removes between themselves,
+ and the get requests from local caches could be
+ divided. The local caches do not need to know
+ anything about the server chaining configuration,
+ unless you want to use a standby, or failover
+ server.
+ </p>
+ <p>
+ We could also use ServerB as a hot standby. This can
+ be done in two ways. You could have all local caches
+ point to ServerA as a primary and ServerB as a
+ secondary. Alternatively, you can set ServerA as the
+ primary for some local caches and ServerB for the
+ primary for some others.
+ </p>
+ <p>
+ The local cache configuration below uses ServerA as
+ a primary and ServerB as a backup. More than one
+ backup can be defined, but only one will be used at
+ a time. If the cache is connected to any server
+ except the primary, it will try to restore the
+ primary connection indefinitely, at 20 second
+ intervals.
+ </p>
+ <source>
+ <![CDATA[
# Remote RMI Cache set up to failover
jcs.auxiliary.RFailover=
org.apache.jcs.auxiliary.remote.RemoteCacheFactory
@@ -234,15 +284,9 @@
localhost:1102,localhost:1103
jcs.auxiliary.RC.attributes.RemoveUponRemotePut=true
jcs.auxiliary.RFailover.attributes.GetOnly=false
- ]]></source>
- <p>
- Note: Since, as of now, the remote cluster servers do not attempt to get items
- from each other, when the primary server comes up, if it does not
- have a disk store, it will be cold. When clustered gets are enable
- or when we have a load all on startup option, this problem
- will be solved.
- </p>
- </subsection>
- </section>
- </body>
+ ]]>
+ </source>
+ </subsection>
+ </section>
+ </body>
</document>
Modified: jakarta/jcs/trunk/xdocs/navigation.xml
URL: http://svn.apache.org/viewvc/jakarta/jcs/trunk/xdocs/navigation.xml?rev=421961&r1=421960&r2=421961&view=diff
==============================================================================
--- jakarta/jcs/trunk/xdocs/navigation.xml (original)
+++ jakarta/jcs/trunk/xdocs/navigation.xml Fri Jul 14 10:44:36 2006
@@ -49,6 +49,8 @@
href="/JDBCDiskCache.html" />
<item name="JDBC Disk Properties"
href="/JDBCDiskCacheProperties.html" />
+ <item name="MySQL Disk Properties"
+ href="/MySQLDiskCacheProperties.html" />
<item name="Remote Cache" href="/RemoteAuxCache.html" />
<item name="Remote Cache Properties"
href="/RemoteCacheProperties.html" />
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-dev-help@jakarta.apache.org