kaz 02/02/20 09:26:57
Modified: xdocs UsingJCSBasicWeb.xml
Log:
- Added links to Aaron's other documentation in appropriate locations.
- Minor formatting changes (typos, <code> blocks, etc.)
Revision Changes Path
1.5 +74 -65 jakarta-turbine-stratum/xdocs/UsingJCSBasicWeb.xml
Index: UsingJCSBasicWeb.xml
===================================================================
RCS file: /home/cvs/jakarta-turbine-stratum/xdocs/UsingJCSBasicWeb.xml,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- UsingJCSBasicWeb.xml 19 Feb 2002 02:31:01 -0000 1.4
+++ UsingJCSBasicWeb.xml 20 Feb 2002 17:26:57 -0000 1.5
@@ -9,24 +9,25 @@
<body>
<section name="Using JCS: Some basics for the web">
<p>
- The primary bottleneck in most dynamic web-based application is
+ The primary bottleneck in most dynamic web-based applications is
the retrieval of data from the database. While it is relatively
- inexpensive to add more front end servers to scale the serving
+ inexpensive to add more front-end servers to scale the serving
of pages and images and the processing of content, it is an
expensive and complex ordeal to scale the database. By taking
advantage of data caching, most web applications can reduce
latency times and scale farther with fewer machines.
</p>
<p>
- JCS is a front tier cache that can be configured to maintain
+ JCS is a front-tier cache that can be configured to maintain
consistency across multiple servers by using a centralized
remote server or by lateral distribution of cache updates.
- Other caches, like the Javlin EJB data cache, are basically in
- memory databases that sit between your EJB's and your database.
- Rather than trying to speed up your slow EJB's, you can avoid
- most of the network traffic and the complexity by implementing
- JCS front tier caching. Centralize your EJB access or you JDBC
- data access into local managers and perform the caching there.
+ Other caches, like the Javlin EJB data cache, are basically
+ in-memory databases that sit between your EJB's and your
+ database. Rather than trying to speed up your slow EJB's, you
+ can avoid most of the network traffic and the complexity by
+ implementing JCS front-tier caching. Centralize your EJB access
+ or your JDBC data access into local managers and perform the
+ caching there.
</p>
<subsection name="What to cache?">
<p>
@@ -72,8 +73,8 @@
create a value object for book data that contains the
necessary information to build the display page. This value
object could hold data from multiple related tables or book
- subtype table, but lets day that you have a simple table
- called BOOK that looks something like this:
+ subtype table, but lets say that you have a simple table
+ called <code>BOOK</code> that looks something like this:
</p>
<source><![CDATA[
Table BOOK
@@ -85,9 +86,9 @@
PUBLISH_DATE
]]></source>
<p>
- We could create a value object for this table called BookVObj
- that has variable with the same names as the table columns
- that might look like this:
+ We could create a value object for this table called
+ <code>BookVObj</code> that has variables with the same
+ names as the table columns that might look like this:
</p>
<source><![CDATA[
package com.genericbookstore.data;
@@ -110,12 +111,14 @@
}
]]></source>
<p>
- Then we can create a manager called BookVObjManager to store
- and retrieve BokVObj's. All access to core book data should
- go through this class, including inserts and updates, to keep
- the caching simple. Let's make BookVObjManager a singleton
- that gets a JCS access object in initialization. The start of
- the class might look like:
+ Then we can create a manager called
+ <code>BookVObjManager</code> to store and retrieve
+ <code>BookVObj</code>'s. All access to core book data
+ should go through this class, including inserts and
+ updates, to keep the caching simple. Let's make
+ <code>BookVObjManager</code> a singleton that gets a
+ JCS access object in initialization. The start of the
+ class might look like:
</p>
<source><![CDATA[
package com.genericbookstore.data;
@@ -171,10 +174,11 @@
}
]]></source>
<p>
- To get a BookVObj we will need some access methods in the
- manager. We should be able to get a non-cached version if
- necessary, say before allowing an administrator to edit the
- book data. The methods might look like:
+ To get a <code>BookVObj</code> we will need some access
+ methods in the manager. We should be able to get a
+ non-cached version if necessary, say before allowing an
+ administrator to edit the book data. The methods might
+ look like:
</p>
<source><![CDATA[
/**
@@ -319,37 +323,39 @@
would create a region that could store a bit over the minimum
number I want to have in memory, so the core items always
readily available. I would set the maximum memory size to
- 1200.
+ <code>1200</code>.
</p>
<p>
- For most cache regions you will want to use a disk cache if
- the data takes over about .5 milliseconds to create. The
- indexed disk cache is the most efficient disk caching
- auxiliary, and for normal usage it is recommended. See the
- documentation.
- </p>
- <p>
- The next step will be to select an appropriate distribution
- layer. If you have a backend server running an apserver or
- scripts or are running multiple webserver vms on one machine,
- you might want to use the centralized remote cache. See
- documentation. The lateral cache would be fine, but since the
- lateral cache binds to a port, you'd have to configure each
- vm's lateral cache to listen to a different port on that
- machine.
- </p>
- <p>
- If your environment is very flat, say a few load-balanced
- webservers and a database machine or one webserver with
- multiple vm's and a database machine, then the lateral cache
- will probably make more sense. The TCP lateral cache is
- recommended. See the documentation.
- </p>
- <p>
- For the book store configuration I will set up a region for
- the bookCache that uses the LRU memory cache, the indexed disk
- auxiliary cache, and the remote cache. The configuration file
- might look like this:
+ For most cache regions you will want to use a disk
+ cache if the data takes over about .5 milliseconds to
+ create. The <a href="IndexedDiskAuxCache.html">indexed
+ disk cache</a> is the most efficient disk caching
+ auxiliary, and for normal usage it is recommended.
+ </p>
+ <p>
+ The next step will be to select an appropriate
+ distribution layer. If you have a back-end server
+ running an apserver or scripts or are running multiple
+ webserver VMs on one machine, you might want to use
+ the centralized <a href="RemoteAuxCache.html">remote
+ cache</a>. The lateral cache would be fine, but since
+ the lateral cache binds to a port, you'd have to configure
+ each VM's lateral cache to listen to a different port on
+ that machine.
+ </p>
+ <p>
+ If your environment is very flat, say a few
+ load-balanced webservers and a database machine or one
+ webserver with multiple VMs and a database machine,
+ then the lateral cache will probably make more sense.
+ The <a href="LateralTCPAuxCache.html">TCP lateral
+ cache</a> is recommended.
+ </p>
+ <p>
+ For the book store configuration I will set up a region
+ for the <code>bookCache</code> that uses the LRU memory
+ cache, the indexed disk auxiliary cache, and the remote
+ cache. The configuration file might look like this:
</p>
<source><![CDATA[
# DEFAULT CACHE REGION
@@ -401,21 +407,24 @@
jcs.auxiliary.RFailover.attributes.GetOnly=false
]]></source>
<p>
- I've set up the default cache settings in the above file to
- approximate the bookCache settings. Other non-preconfigured
- cache regions will use the default settings. You only have to
- configure the auxiliary caches once. For most caches you will
- not need to pre-configure our regions unless the size of the
- elements varies radically. We could easily put several
- hundred thousand BookVObj's in memory. The 1200 limit was
- very conservative and would be more appropriate for a large
+ I've set up the default cache settings in the above
+ file to approximate the <code>bookCache</code>
+ settings. Other non-preconfigured cache regions will
+ use the default settings. You only have to configure
+ the auxiliary caches once. For most caches you will
+ not need to pre-configure your regions unless the size
+ of the elements varies radically. We could easily put
+ several hundred thousand <code>BookVObj</code>'s in
+ memory. The <code>1200</code> limit was very
+ conservative and would be more appropriate for a large
data structure.
</p>
<p>
- To get running with the book store example, I will also need
- to start up the remote cache server on the scriptserver
- machine. The remote cache documentation describes the
- configuration.
+ To get running with the book store example, I will also
+ need to start up the remote cache server on the
+ scriptserver machine. The
+ <a href="RemoteAuxCache.html">remote cache
+ documentation</a> describes the configuration.
</p>
<p>
I now have a basic caching system implemented for my book
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
