Hi,
I have not followed the whole discussion, but two things sound strange to me
:
1) Why do you want to store the connection if it comes from a connection
pool ? You should just request a connection from the pool, use it, and
return it to the pool as soon as you don't need it anymore. A pool is as
efficient as you are efficient using it. The principle is that nobody keeps
control over pooled objects longer than necessary.
2) If you want to store an object so that it will be available to all
threads going through your servlet, just create a member reference and
assign this object to it. In other word, rather than trying to store the
object in a the servlet context , or in the request, just store it in your
servlet. You can even make this reference static if you are using a single
thread model.
Pierre-Yves
-----Message d'origine-----
De : A mailing list for discussion about Sun Microsystem's Java Servlet
API Technology. [mailto:[EMAIL PROTECTED]]De la part de Andi
Setiyadi
Envoy� : lundi 30 avril 2001 23:08
� : [EMAIL PROTECTED]
Objet : Re: Session & Database connection
Hi Geeta,
Thank you for the response. Referring from the previous reply on this
topic, it is not recommended to store the connection in a session, since
connection object will have to be created each time a user makes a request
to our servlet. That's why I am trying to put in servletcontext object.
I also have tried to put the connection in request object:
request.setAttribute("connection", myConnection); // in first servlet
then in the second servlet just call request.getAttribute("connection");
Can anybody explain to me if there is any drawback doing it this way and
not in servletcontext? is servletcontext the appropriate place to store
connection object from connectionPool?
Thank you.
Andi Setiyadi
Geeta Ramani
<[EMAIL PROTECTED] To:
[EMAIL PROTECTED]
OM> cc:
Sent by: "A mailing Subject: Re: Session &
Database connection
list for discussion
about Sun
Microsystem's Java
Servlet API
Technology."
<SERVLET-INTEREST@JAV
A.SUN.COM>
04/30/01 01:44 PM
Please respond to "A
mailing list for
discussion about Sun
Microsystem's Java
Servlet API
Technology."
Hi Andi;
Since code in the init() method is executed *exactly* once at servlet
initialization time (*not*
once per request), you wouldn't want to have:
context.setAttribute("connection", connection");
in the init method at all. (Because i don't imagine you want to share the
connection object amongst
all users.)
Instead you want to initialize the ConnectionPool in the init method (since
that needs to be done
be only once), and in the doPost/doGet (of the first servlet) you may want
to have code like this:
HttpSession session = req.getSession(true);
Connection connection = myConnectionPool.getconnection();
session.setAttribute("connection", connection);
Then in your second servlet you should be able to access that connection
object via:
HttpSession session = req.getSession(false); //dont create a session if one
doesn't exist
if (session == null){
//code for redirecting to first sevlet..
}
else {
Connection connection = session.getAttribute("connection");
//etc.
}
Andi Setiyadi wrote:
> I try to use connection pooling to make database connection and put the
> connection object in ServletContext. Here is how my application work.
> - user login through JSP and submit the request which handled by first
> level servlet. In the init( ), I did:
> ServletContext context = getServletContext( ), then make database
> connection and put in the attribute
> context.setAttribute("connection", connection");
>
> - first level servlet then call second level servlet. In the second
> servlet I try to getServletContext( ):
> ServletContext context = getServletContext( );
>
> When executing that line, I got the following error:
>
> null
> java.lang.NullPointerException
> at
> javax.servlet.GenericServlet.getServletContext(GenericServlet.java:205)
> at
com.wg.hr.PersonnetWelcome.execute(PersonnetWelcome.java:37)
> at com.wg.hr.Personnet.doGet(Personnet.java:67)
> at com.wg.hr.Personnet.doPost(Personnet.java:85)
> ...
>
> Any suggestion is appreciated
> Thanks,
> Andi
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
