hlship 2003/08/06 11:50:05
Modified: hivemind/xdocs navigation.xml
Added: hivemind/xdocs multithreading.xml
Log:
Add documentation about multi-threading issues.
Revision Changes Path
1.12 +1 -0 jakarta-commons-sandbox/hivemind/xdocs/navigation.xml
Index: navigation.xml
===================================================================
RCS file: /home/cvs/jakarta-commons-sandbox/hivemind/xdocs/navigation.xml,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- navigation.xml 31 Jul 2003 21:06:24 -0000 1.11
+++ navigation.xml 6 Aug 2003 18:50:05 -0000 1.12
@@ -7,6 +7,7 @@
<item name="Extension Points" href="/extension-points.html"/>
<item name="Localization" href="/localization.html"/>
<item name="Inversion of Control" href="/ioc.html"/>
+ <item name="Multi-Threading" href="/multithreading.html"/>
<item name="Module Descriptor" href="/descriptor.html"
collapse="true">
<item name="XML Processing Rules" href="/rules.html"/>
</item>
1.1 jakarta-commons-sandbox/hivemind/xdocs/multithreading.xml
Index: multithreading.xml
===================================================================
<?xml version="1.0"?>
<!-- $Id: multithreading.xml,v 1.1 2003/08/06 18:50:05 hlship Exp $ -->
<!DOCTYPE document [
<!ENTITY % common-links SYSTEM "../common/links.xml">
%common-links;
]>
<document>
<properties>
<title>HiveMind Multi-Threading</title>
<author email="[EMAIL PROTECTED]">Howard M. Lewis Ship</author>
</properties>
<body>
<section name="Multi-Threading">
<p>
HiveMind is specifically targetted for J2EE: deployment in a WAR or EAR, particularly
as part of a <a href="http://jakarta.apache.org/tapestry";>Tapestry</a>
application. Of course,
J2EE is not a requirement, and HiveMind is quite useful even in a simple, standalone
environment.
</p>
<p>
In J2EE world, multi-threading is an issue. HiveMind services are all singletons,
and must
be prepared to operate in a multi-threaded environment. That means services should
not have
any specific state, much like a servlet.
</p>
</section>
<section name="Construction State">
<p>
HiveMind expects that initially, work will progress in a single startup thread. This
is the early state, the construction state, where the module deployment descriptors
are located and parsed, and the contents used to assemble the registry; this is the
domain of
<a
href="apidocs/org/apache/commons/hivemind/impl/RegistryBuilder.html">RegistryBuilder</a>
.
</p>
<p>
The construction activities are not threadsafe. This includes the parser, and other
code (virtually all of which is hidden from your application).
</p>
<p>
The construction state ends when the <code>RegistryBuilder</code> returns
the
<a href="apidocs/org/apache/commons/hivemind/Registry.html">Registry</a>
from method <code>constructRegistry()</code>. The registry is threadsafe.
</p>
</section>
<section name="Runtime State">
<p>
Everything that occurs with the registry and modules must be threadsafe. Key methods
are always synchronized. In particular, the methods that construct a service
and construct extension point elements are threadsafe. Operations such as building
the interceptor stack,
instantiating core service implementations, and converting XML to Java objects
operate in a threadsafe manner. However, different threads may be building different
services simultaneously. This means that, for example, an interceptor service must
still be threadsafe, since
it may be called upon to generate interceptors for two or more
different services simultaneously.
</p>
<p>
On the other hand, the Java objects constructed from XML &rules; don't need to be
threadsafe, since that construction is synchronized properly ... only a single thread
will be converting XML to Java objects for any single extension point.
</p>
</section>
</body>
</document>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
