>so if different client uses different browser (not different browser
>instance) to access your Servlet class, I think the Servlet container will
>make/keep
>different insatnce of HttpSession, i.e., req.getSession(true) will return
>different session
This is generally true, but not always. The server receives a session ID and
retrieves the corresponding session. It has no other knowledge of who
exactly is requesting. If session ID comes from a cookie, it could be shared
among several clients. The fact that it is not the case with the browsers we
generally use doesn't mean that it is not possible. It would make sense for
to different versions of a browser to share cookies. It would even make
sense to manage cookies at the user level and not at the client (browser or
anything else) level.
Also, the same browser from the same computer will not send the same cookies
depending with which user name you loggin.
And if the ID comes from url rewriting, the url can be copied and shared
among users. (I gave an example of this in a post two days ago).
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 Bo
Xu
Envoy� : vendredi 27 avril 2001 23:27
� : [EMAIL PROTECTED]
Objet : Re: Session & Database connection
Andi Setiyadi wrote:
> I have a question about database connection.
> In the code below, what happen when one request has just creating a
session
> for storing the connection, and the another request is about to execute
> session.removeAttribute that will kill the session? Is the session unique
> for each request, means that when one user kill connection session will
not
> affect other user's connection session? Or all request share the same
> connection session?
> Is this a good way to maintain connection for each request? Why?
>
> Thank you. I appreciated any input.
>
> Andi Setiyadi
>
> Attached code:
>
> public void doGet(HttpServletRequest req, HttpServletResponse res) throws
> IOException, ServletException {
>
> HttpSession session = req.getSession(true);
> Connection conn;
>
> synchronized(session) {
> conn = (Connection) session.getAttribute("connection");
> if (conn == null) {
> ConnectionBean cBean = new ConnectionBean();
> conn = cBean.getConnection();
> session.setAttribute("connection", conn);
> }
> }
>
> // perform some tasks
> ...
>
> try {
> if (conn != null) {
> conn.close();
> }
> }
>
> catch(Exception e) { }
>
> session.removeAttribute("connection");
> }
> [...]
Hi :-) just IMHO, because a HttpSession is a "identify" of a connection
between a browser and a "Servlet Container+webapp+...?" within a period
of time, so if different client uses different browser (not different
browser
instance) to access your Servlet class, I think the Servlet container will
make/keep
different insatnce of HttpSession, i.e., req.getSession(true) will return
different
session, I just made a test with TOMCAT4.0b1(standalone, J2SE1.3, winnt40),
I use IE5.0 and NN4.7 in my computer to visit MyServlet, and I got different
hashCode() of two sessions.
and I guess perhaps it is better to maintain DBConnection with a
DBConnectionPool, for example :
* make a SingleTon-style DBConnectionPool, let its class be loaded by
a classloader which is "upper" webapp classloader(for example, put its
class in TOMCAT_HOME/lib) if I use TOMCAT, and in init() or
somewhere else, I "init" it, and got a onlyone instance.
* directly use the static refrence within its class to use that onlyone
instance of DBConnectionPool, or put that instance in ServletContext
so we can get a refrence of it later.
* we can put all the "synchronized operation" within DBConnectionPool
itsself, i.e.
- we can use "this" of DBConnectionPool to lock code because of
it is SingleTon-style
- or use this.getClass() to lock code, because we load it with a
classloader
which will not be destroyed.
* if I Don't put the "synchronized operation" within DBConnectionPool
itsself,
we also can use some "wide area onlyone thing within container" to lock
the
code, for example (in TC4.0bx):
- this.getServletContext()
- this.getServletContext().getClass()
- this.getServletContext().getClass().getClassLoader()
- session.getClass()
- session.getClass().getClassLoader()
- ...
Bo
Apr.27, 2001
___________________________________________________________________________
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
