- Often you see the singleton design pattern being used for Java services in the context of a servlet. Most often this is I see this done
for JDBC connection brokers. You can imagine how useful it is to be able to statically
access and request a JDBC connection without having to pass a pointer around.
Using a static variable to reference obviously makes things easier, but at what cost? Using
a static reference works well if you only have one application running inside a single JVM.
However servlets may, or may not work that way. You don't know. Most servlet runtime
environments in fact do run all servlets inside a single JVM.
- So the result is that static reference is shared between all servlets, in this case
a JDBC Broker. This poses a couple problems. Now a single rogue servlet can disable
all other servlets running on a server by modifying that static reference. One servlet
cannot modify the settings on the static variable without risking interfering with the
operation of other servlets.
- The original design of apollo used a static holder to allow easy access to the
PageManager, LogManager and the other services without having to pass around a pointer.
This had to be quickly phased out because
as soon as a second servlet started on the same server, it would reprogram the PageManager
with the second servlets Page tree, disabling the first servlet. What apollo now uses is
may seem something less then ideal. There is an object called the ManagerTracker (MT for short),
which is required to access any of apollo's services. This, unfortunately, means you
need to pass this object into the constructors of any objects which need a ManagerTracker
reference. This can become frustrating at times, but the alternative, a singleton reference
to the ManagerTracker, is even worse. Although apollo encourages the use of a non-singleton
approach, apollo should still function if a singleton reference is used. If the final
deployment is in a controlled environment, a singleton reference could be used, but it may end up
being a dangerous design decision.