HiveMind Multi-Threading
HiveMind is specifically targetted for J2EE: deployment in a WAR or EAR, particularly as part of a Tapestry application. Of course, J2EE is not a requirement, and HiveMind is quite useful even in a simple, standalone environment.
In the world of J2EE, multi-threading is always an issue. HiveMind services are usually 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.
Construction State
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 RegistryBuilder .
The construction activities are not thread-safe. This includes the parser, and other code (virtually all of which is hidden from your application).
The construction state ends when the RegistryBuilder returns the Registry from method constructRegistry(). The registry is thread-safe.
Runtime State
Everything that occurs with the Registry and modules must be thread-safe. Key methods are always synchronized. In particular, the methods that construct a service and construct configuration point elements are thread-safe. Operations such as building the interceptor stack, instantiating core service implementations, and converting XML to Java objects operate in a thread-safe manner. However, different threads may be building different services simultaneously. This means that, for example, an interceptor service implementation must still be thread-safe, since it may be called upon to generate interceptors for two or more different services simultaneously.
On the other hand, the Java objects constructed from XML <rules> don't need to be thread-safe, since that construction is synchronized properly ... only a single thread will be converting XML to Java objects for any single configuration point.
Managing Service State
When services simply must maintain state between method invocations, there are several good options:
- Store the data in an object passed to or returned from the service
- Make use of the hivemind.ThreadLocalStorage service to store the data in a thread-local map.
- Make use of the threaded or pooled service models, which allow a service to keep its state between service method invocations.