bloritsch 2002/09/25 14:20:38
Modified: event/src/xdocs menu.xml
Added: event/src/xdocs mpool.xml
Log:
Add docs for MPool
Revision Changes Path
1.4 +2 -2 jakarta-avalon-excalibur/event/src/xdocs/menu.xml
Index: menu.xml
===================================================================
RCS file: /home/cvs/jakarta-avalon-excalibur/event/src/xdocs/menu.xml,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- menu.xml 25 Sep 2002 20:03:56 -0000 1.3
+++ menu.xml 25 Sep 2002 21:20:38 -0000 1.4
@@ -13,8 +13,8 @@
<menu name="Overview">
<item href="event.html" name="Event"/>
<item href="command.html" name="Command"/>
- <!-- <item href="mpool.html" name="MPool"/>
- <item href="thread.html" name="Thread"/>
+ <item href="mpool.html" name="MPool"/>
+ <!-- <item href="thread.html" name="Thread"/>
<item href="util.html" name="Util"/> -->
</menu>
<!--
1.1 jakarta-avalon-excalibur/event/src/xdocs/mpool.xml
Index: mpool.xml
===================================================================
<?xml version="1.0"?>
<document>
<header>
<title>Excalibur Event - MPool (Managed Pool)</title>
<authors>
<person name="Berin Loritsch" email="[EMAIL PROTECTED]"/>
</authors>
</header>
<body>
<s1 title="Why MPool Was Created">
<p>
MPool (Managed Pool) was created as an experiment in dynamic
pool management. The theory is that by determining whether to
shrink or grow a pool can be a costly endeavor. That is
especially true when you want to play with "intelligent" pools.
</p>
<p>
What we observed after we used MPool in practice is that under
load, pool sizing algorithms begin to choke the efficiency of
the pool. In fact, it can get so bad that it would be better
not to have a pool at all. An unbounded pool (one that does
not shrink) is a resource hog, especially during inactive times.
By moving the pool sizing logic into an asyncronous Command,
we were able to achieve the efficiency of an unbounded pool
while keeping an eye on pool size. During times of inactivity
we destroy pooled objects that we don't need. During times of
stress, we create a new object immediately and in a background
process we add new objects.
</p>
</s1>
<s1 title="When To Use MPool">
<p>
Use MPool any time you need a pool without hard limits, and you
expect heavy loads. The pool size is checked periodically, so
we don't incur extra overhead of having to check that while the
pool size grows and shrinks.
</p>
</s1>
<s1 title="Core Concepts">
<p>
MPool has two pool types: fixed size and variable size. A fixed
size pool is not managed externally. There is a fixed limit to
the number of resources it can manage so we don't have to manage
it. A variable sized pool is a managed pool. A managed pool will
be created by the PoolManager, and that manager will manage all
of its pool sizes in the background.
</p>
<s2 title="Object Factory">
<p>
An Object Factory is what the pools use to create new objects
or destroy old ones. They are particularly helpful when there
is a complex creation/destruction policy. They are also essential
for ManagablePools.
</p>
</s2>
<s2 title="Pool">
<p>
The base Pool interface is how the client code interacts with
the pool. You acquire and release pooled objects from the
pool.
</p>
</s2>
<s2 title="Managable Pool">
<p>
A Managable Pool is a special interface that allows a PoolManager
to register itself with a "magic key" so that the managed pool
only responds to the PoolManager responsible for it.
</p>
</s2>
<s2 title="Pool Manager">
<p>
The Pool Manager is how you obtain a Managable Pool. It also
takes care of the management functions for that pool.
</p>
</s2>
</s1>
</body>
<footer>
<legal>
Copyright (c) @year@ The Jakarta Apache Project All rights reserved.
$Revision: 1.1 $ $Date: 2002/09/25 21:20:38 $
</legal>
</footer>
</document>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
