While you are reading the JavaDoc of APIs in Bento framework, you may notice that the core class of each API does not implement the public constructor. For instance, the core class of OOP MimeParser API is:
but you will not find its public constructor. To get the instance of this class, please use its static method:
Please click the link below and look into the example source code:
| [ Example Source Code of MimeParser ... ] |
Or, in case of OOP LoginManager API, the core interface is:
Because this is an interface, there is no public constructor. To get the instance of this interface, you need to get the instance of its Factory class first. It is:
Please click the link below and look into the example source code:
| [ Example Source Code of LoginManager ... ] |
Each time you create the instance of the class by its constructor, you will get the new instance of that class. Contrarily,
(or its variant) always returns the same instance of the expected class. Please click the links below and look into the example source code:
| [ Instances by constructor ... ] |
| [ Same Instance by Singleton Pattern ... ] |
For details about Singleton Pattern, please read:
Because Servlet/JSP must be prepared for the multiple simultaneous requests, you must make your Servlet/JSP Thread Safe, unless your Servlet/JSP implements Single Thread Model interface. To make your Servlet/JSP Thread Safe, the state of the variable must not be affected by the subsequent requests to your Servlet/JSP. As a general rule, you should use local variable instead of member variable in your Servlet/JSP. Please click the links below and compare the 2 source code example:
| [ Non Thread Safe Servlet by member variable (bad example) ... ] |
| [ Thread Safe Servlet by local variable (good example) ... ] |
But, in the good example above, one instance of:
is created for each invocation of method. This results in the 10000 of object creations, if your Servlet/JSP accepts 10000 requests. The bad news is ... an object creation is a somewhat heavy task for JVM. In addition, the instance will be the subject of garbage collection later. While the modern JVMs in these days are well designed for avoiding the over-heads related with garbage collection, but less, the better.
The good news is ... In case that the state is not overridden by the subsequent requests, member variable does no harm. Please click the link below and look into another example source code:
| [ Thread Safe Servlet by member variable (better example) ... ] |
As possible as we can, we implement the core class of our API in as similer way like:
in the above example. Your Servlet/JSP can be Thread Safe with its member variable, and can avoid the repeated object creations.
As shown above, a single instance of the core class can be shared by multiple requests to a single Servlet/JSP. The good news is ... such a single instance can be shared also by multiple Servlet/JSP if it is created by:
or its variant. This is why the core class of our API does not implement the public constructor, but implements:
or its variant.
Because the core class of our API implements very complex features, there are many initialization parameters to be specified. For instance, the core class of OOP LoginManager API needs the 18 SQL statements as the initialization parameters. Only at the first initialization time, these paramaters should be loaded from the property files or XML in:
by:
or its variant method. Once the single instance is created by the first call, the subsequent calls of:
do not create the second instance. The subsequent calls just return the single instance that was created by the first call, and that's all. The property files and XML are never read again.
In other words, you can safely call:
repeatedly.
As for the subsequent calls, this method just returns the same instance which is returned by the first call, and does not read any XML or property files. Thus, this method gives us the way to get the reference to the single instance from anywhere within a web application context. By this method, any JSP or Servlet within the same web application context can share the single instance. Do not use the constructor to initialize the instance of the class. Instead, please write something like:
It is easy, isn't it? By the way, you may have noticed that the first call of this method may be somewhat heavy task. Yes, it is desirable to avoid calling this method within:
Rather, the best place to live for this method is:
and your Servlet/JSP can keep the class-scoped variable for the returned instance. Then,
can call other methods on it, because they are Thread Safe. Please click the links below and look into the example source code:
| [ Example Source Code ... ] |
In the above example, the Servlet gets the single instance of MimeParser, which is the core class of OOP MimeParser API. Other Servlets within the same web application may also implement the init( ) method in a same way, and the same instance of MimeParser can be shared among all the Servlets within the same web application.
NOTE:
This article was written when Servlet 2.2 Spec was finalized.
If your environment complies with Servlet 2.3 Spec, ServletContextListner will be the better place for this job.
For details, please read J2EE Tech Tips.
, which closes all the JDBC Connections to SQL database. Another example is MailScheduler, the core class of OOP MailScheduler. Its instance keeps the background Thread running, which sends the e-mails at the scheduled time. To start/stop this background Thread, we should call:
independently from the HTTP requests from the web browser. As you know, the best places for these start-up and clean-up tasks are:
of your Servlet. Apache Tomcat (or any other Servlet/JSP server) calls these methods on all the available Servlets in it, at the boot time and before it shutdowns correspondingly. For example, one of your Servlets may implement:
public void init()
throws ServletException{
try{
PooledPS.getInstance();
SimpleSMTP smtp=SimpleSMTP.getInstance();
MailScheduler.getInstance(smtp).startScheduler();
}
catch(Exception ex){
throw (new ServletException(ex));
}
}
public void destroy(){
MailScheduler.getInstance().stopScheduler();
// Because MailScheduler depends on PooledPS,
// call this method at the very last!
PooledPS.closeIfOpen();
}
|
Because both of start-up and clean-up tasks should be done only once, only one Servlet should be responsible for these tasks. The good practice is to define a special kind of Servlet (you can think of it dummy Servlet), whose purposes are:
only. Such a Servlet does not need to implement any of:
Because any HTTP requests will never arrive in that Servlet, the Servlet must be loaded into Apache Tomcat (or any other Servlet/JSP server) explicitly. In the web.xml for your web application context, load-on-startup element can force Apache Tomcat (or any other Servlet server) to load the Servlet at the start-up time of the server. For example, assuming that the class name of the Servlet is InitAndDestroy, your web.xml will include the elements like below:
<servlet>
<servlet-name>
dummy
</servlet-name>
<servlet-class>
InitAndDestroy
</servlet-class>
<load-on-startup>
1
</load-on-startup>
</servlet>
|
Then, Apache Tomcat (or any other Servlet server) will load this dummy Servlet and call its init( ) destroy( ) methods. Thus, by the benefit of load-on-startup mechanism, dummy Servlet can play a significant role in your web applications or WAP services while it is invisible to the users.
Copyright © 1997-2010 OOP-Research CorporationTM, All Rights Reserved.
