You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by hl...@apache.org on 2003/08/06 20:50:05 UTC
cvs commit: jakarta-commons-sandbox/hivemind/xdocs multithreading.xml navigation.xml
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="hlship@apache.org">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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org