You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Geeta Ramani <gr...@terralink.com> on 2004/04/29 18:38:28 UTC
RE: [OT] dbcp, the finally block, and setting connection object to null after closing it.
Wait a minute. Are you then saying that conn.close() does nothing? I would have presumed that conn.close() releases the connection to the pool and once you exit the method, you (i.e. the method) has no more reference to it and so forth..? Am I going nuts???
> -----Original Message-----
> From: dennis.graham@wachovia.com [mailto:dennis.graham@wachovia.com]
> Sent: Thursday, April 29, 2004 12:40 PM
> To: Struts Users Mailing List
> Cc: Struts Users Mailing List
> Subject: RE: [OT] dbcp, the finally block, and setting
> connection object
> to null after closing it.
>
>
> "conn" is just a reference. If you don't release your connection
> reference, you will eventually exhaust the connection
> pool....and that
> would (probably) be a Bad Thing.
>
> Dennis Graham
>
>
>
>
>
>
> "Geeta Ramani" <gr...@terralink.com>
> 04/29/2004 12:16 PM
> Please respond to "Struts Users Mailing List"
>
> To: "Struts Users Mailing List" <us...@struts.apache.org>
> cc:
> Subject: RE: [OT] dbcp, the finally block, and setting
> connection object to null after closing it.
>
>
> um.. so are you saying that in the finally block that piece
> of code "conn
> = null;" should in fact *not* be there..? Well, in that case,
> yes, that is
> what i also thought and that's (partly) why I mentioned
> earlier that that
> statement may not want to be there.. But it was added pretty
> deliberately,
> so I cannot believe this could be the case..?
>
> Thank you again for your response!
> Geeta
>
> > -----Original Message-----
> > From: MARU, SOHIL (SBCSI) [mailto:sm8971@sbc.com]
> > Sent: Thursday, April 29, 2004 12:09 PM
> > To: Struts Users Mailing List
> > Subject: RE: [OT] dbcp, the finally block, and setting
> > connection object
> > to null after closing it.
> >
> >
> > The problem in that list says that a connection cannot be used after
> > calling close on it. By setting it to null, you will just change the
> > SQLException to a Null Pointer exception when it is used again.
> >
> > -----Original Message-----
> > From: Geeta Ramani [mailto:gramani@terralink.com]
> > Sent: Thursday, April 29, 2004 10:55 AM
> > To: Struts Users Mailing List
> > Subject: RE: [OT] dbcp, the finally block, and setting
> > connection object
> > to null after closing it.
> >
> >
> > Yes, the code in
> > http://www.mail-archive.com/commons-user@jakarta.apache.org/ms
> > g06123.htm
> > l implies it is a method variable. I would have thought the
> > same as you
> > suggest below, but the reason i assumed something more was
> > going on was
> > (i)Craig wrote it so it's gotta to be useful..;) (ii)
> googling gave me
> > this page:
> > http://manuals.sybase.com/onlinebooks/group-jcarc/jcg0400e/jcr
> > g/@Generic
> > __BookTextView/7402 and I was looking into error JZ0C0
> > against which is
> > "Action: Fix the code so that Connection object references
> are nulled
> > out whenever a connection is closed." I know they aren't
> > referring to a
> > connection got from a pool but coupled with Craig's code, i couldn't
> > help wondering..
> >
> > But thanks for your reply anyway!
> > Geeta
> >
> > > -----Original Message-----
> > > From: MARU, SOHIL (SBCSI) [mailto:sm8971@sbc.com]
> > > Sent: Thursday, April 29, 2004 11:57 AM
> > > To: Struts Users Mailing List
> > > Subject: RE: [OT] dbcp, the finally block, and setting
> > > connection object
> > > to null after closing it.
> > >
> > >
> > > It depends on where the variable conn is defined. If it is
> > > defined to be
> > > a static/instance(God knows why but I have seen enough of such bad
> > > code), this is a way of not keeping a reference to that
> Connection.
> > >
> > > You would explicitly set a variable to null to let the
> > > garbage collector
> > > know its safe to reclaim the associated object. Ideally, if
> > conn is a
> > > method variable, this statement(conn = null) wont do much
> > as when the
> > > variable goes out of scope, the associated instance is
> > > returned to pool
> > > which still has reference to it and so it will not be garbage
> > > collected.
> > >
> > >
> > > -----Original Message-----
> > > From: Geeta Ramani [mailto:gramani@terralink.com]
> > > Sent: Thursday, April 29, 2004 10:42 AM
> > > To: Struts Users Mailing List (E-mail)
> > > Subject: [OT] dbcp, the finally block, and setting connection
> > > object to
> > > null after closing it.
> > >
> > >
> > > Hey again everyone.
> > >
> > > This is I know the wrong list to post to, but believe me (and
> > > read below
> > > if you want the gory details), i tried to post to the right
> > > list and got
> > > nowhere.
> > >
> > > Here's the post I would like some clarification on:
> > >
> > > http://www.mail-archive.com/commons-user@jakarta.apache.org/ms
> > > g06123.htm
> > > l
> > >
> > > Notice way down in the "finally" block this piece of code:
> > >
> > > if (conn != null) {
> > > try {
> > > conn.close();
> > > } catch (SQLException e) {
> > > ;
> > > }
> > > conn = null;
> > > }
> > >
> > > My question, briefly is this: What does the conn = null;
> > do? It almost
> > > seems to me that that should not be there.. Doesn't it kind
> > > of take away
> > > the point of having a pool in the first place if every time
> > > you return a
> > > connection to the pool, you kind of render it useless for
> > the next guy
> > > by setting it to null..?
> > >
> > > Thanks a lot in advance!
> > > Geeta
> > >
> > > ------------------------------------------------
> > >
> > > And for the curious, here's what i did: googled for a few
> > hours, then
> > > found most of the answers to the problem I was originally
> set out to
> > > solve. Except I was flummoxed on this conn = null; bit. So I
> > > joined the
> > > commons-user list and then actually read the instructions in my
> > > "welcome" letter. Here's what it says: To receive all
> > > messages with the
> > > same subject as message 12345,
> > > send an empty message to:
> > > <co...@jakarta.apache.org>. Cool. So i sent a
> > > message to
> > > commons-user-thread.06123@jakarta.apache.org. Did I get all
> > > messages..etc.? No. The messages I got had nothing to do with this
> > > posting. Course I could have used the "Reply via email to
> > > Craig" link on
> > > the page above, but hey, that's even worse than writing to
> > this list,
> > > right?! Anyways, since by now I had spent close to a day on
> > > what was I
> > > thought was a simple problem, I gave in to my baser instincts ..
> > >
> > > What was my original problem? I am using the dbcp
> > connection pool with
> > > tomcat for my struts app. Everything works great.
> *Except* when the
> > > (sybase) database server goes down. In which case, tomcat
> has to be
> > > restarted before things will work again. Googling told me
> > > two possible
> > > solutions: use the "validationQuery" parameter to ping the
> > > database and
> > > also to "Fix the code so that Connection object references
> > are nulled
> > > out whenever a connection is closed." To be doubly sure, i
> > > decided to do
> > > both. And while looking into the latter "solution", I came across
> > > Craig's note above.. So now you know: I am stupid, but I am
> > > not lazy..;)
> > >
> > >
> >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > > For additional commands, e-mail: user-help@struts.apache.org
> > >
> > >
> > >
> >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > > For additional commands, e-mail: user-help@struts.apache.org
> > >
> > >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org