You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Christopher Schultz <ch...@christopherschultz.net> on 2009/11/07 02:54:30 UTC
Re: [OT] ConnectionPool question
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Elli,
Okay, I think we've hijacked Josh's thread enough to at least mark it as
off topic. :)
On 11/5/2009 10:37 PM, Elli Albek wrote:
> Christopher Schultz wrote:
>> Pooled connections are almost certainly not behaving this way. This has
>> been discussed at least twice in the last week or two, and, I believe,
>> already once in this thread.
>
> This is certainly not the case for my DBCP library (1.2.2). I just
> stepped through the source code: Calling connection.close() is closing
> result sets and statements.
I'm not sure how calling Connection.close (where the Connection object
is one from DBCP) would possibly be able to close ResultSet and
Statement objects created by the underlying connection.
Unless, I suppose, they decided to wrap /everything/ and register all
the ResultSet and Statement objects handed-out by the underlying
Connection for the purposes of (possibly) closing them later. I should
really read the source :)
> Below is the DBCP code that keeps track of open statements/result sets
> and closes them when the connection is closed (BDCP 1.2.2).
Yup: it looks like they do wrap/register everything and then close it
for you. It's nice that they followed the spec, here :)
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkr001YACgkQ9CaO5/Lv0PDKfgCgl0DRVzft7OkckYlzs4IsBcYu
wvsAoIRysepHLxAW7wBznL0vfaJhy/ll
=tTmF
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] ConnectionPool question
Posted by Josh Gooding <jo...@gmail.com>.
Yup,
No wonder my shop is in so much trouble. No procedures, no brainstorming,
no project management, no best practices, just a "shoot from the hip,
Git-R-Done" attitude.
I liked that so much it's now hanging in my cube :)
- Josh
On Wed, Nov 11, 2009 at 3:33 PM, Caldarale, Charles R <
Chuck.Caldarale@unisys.com> wrote:
> > From: Josh Gooding [mailto:josh.gooding@gmail.com]
> > Subject: Re: [OT] ConnectionPool question
> >
> > Not only did I get yelled at for having the audacity to write up
> > procedures for the developers on my team
>
> "But we've always done it that way..."
>
> "A long habit of not thinking a thing wrong, gives it a superficial
> appearance of being right."
> - Thomas Paine, 1776
>
> - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
> MATERIAL and is thus for use only by the intended recipient. If you received
> this in error, please contact the sender and delete the e-mail and its
> attachments from all computers.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
RE: [OT] ConnectionPool question
Posted by "Propes, Barry L " <ba...@citi.com>.
That's good stuff, Chuck - and sadly, so prevalent among many places as the thought process.
-----Original Message-----
From: Caldarale, Charles R [mailto:Chuck.Caldarale@unisys.com]
Sent: Wednesday, November 11, 2009 2:34 PM
To: Tomcat Users List
Subject: RE: [OT] ConnectionPool question
> From: Josh Gooding [mailto:josh.gooding@gmail.com]
> Subject: Re: [OT] ConnectionPool question
>
> Not only did I get yelled at for having the audacity to write up
> procedures for the developers on my team
"But we've always done it that way..."
"A long habit of not thinking a thing wrong, gives it a superficial appearance of being right."
- Thomas Paine, 1776
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [OT] ConnectionPool question
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Josh Gooding [mailto:josh.gooding@gmail.com]
> Subject: Re: [OT] ConnectionPool question
>
> Not only did I get yelled at for having the audacity to write up
> procedures for the developers on my team
"But we've always done it that way..."
"A long habit of not thinking a thing wrong, gives it a superficial appearance of being right."
- Thomas Paine, 1776
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] ConnectionPool question
Posted by Josh Gooding <jo...@gmail.com>.
Chris,
I AM going to use Elli's suggestion. It's going to take some time, but I
don't have to worry, once it's done, it'll be done correctly.
Not only did I get yelled at for having the audacity to write up procedures
for the developers on my team (assuming I ever get a another team), but I
told my company that the procedures I wrote up needed to be used on ALL dev
teams. I thought 99% of it was common sense, but I guess not.
On Tue, Nov 10, 2009 at 3:40 PM, Christopher Schultz <
chris@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Josh,
>
> On 11/10/2009 9:18 AM, Josh Gooding wrote:
> > the reason there are multiple recycleConnection methods is because if a
> RS
> > is passed to the front presentation layer, I have to have a way to close
> it,
> > I have to be able to get the statement and connection somehow, and I
> don't
> > want that in my code.
>
> I was assuming that you were going to use Elli's suggestion to use a
> ThreadLocal to capture any allocated Connection objects, and just close
> everything at the end of the request processing.
>
> If you're going to do that, you can be lazy about it and just always
> close everything.
>
> >>From everything that everyone here has said, to semi fix this right:
> >
> > 1 - Each method that calls the DB for a RS needs to get it's own
> connection
> > and close the resources itself (keeping it in the same scope)
>
> This is, of course, recommended technique.
>
> > 2 - The CP wrapper that is here, CAN be used, but could end up causing
> more
> > problems in the long run.
>
> Well, yes and no. "Yes" in the sense that you shouldn't encourage the
> kind of coding behavior that's been exhibited in the past: by writing
> such a wrapper and clean-up code, you (might) encourage laziness and
> make the problem worse rather than better. "No" in the sense that I
> don't believe this solution is actually going to exacerbate the actual
> problem itself.
>
> Good luck,
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkr5z7AACgkQ9CaO5/Lv0PCM5ACfdA3MPnJ/YEeUwIeuNjh9akH7
> 2X4AoKyfvWVdOv59FJtxMrw4nyLxsrk9
> =WWP3
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: [OT] ConnectionPool question
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Josh,
On 11/10/2009 9:18 AM, Josh Gooding wrote:
> the reason there are multiple recycleConnection methods is because if a RS
> is passed to the front presentation layer, I have to have a way to close it,
> I have to be able to get the statement and connection somehow, and I don't
> want that in my code.
I was assuming that you were going to use Elli's suggestion to use a
ThreadLocal to capture any allocated Connection objects, and just close
everything at the end of the request processing.
If you're going to do that, you can be lazy about it and just always
close everything.
>>>From everything that everyone here has said, to semi fix this right:
>
> 1 - Each method that calls the DB for a RS needs to get it's own connection
> and close the resources itself (keeping it in the same scope)
This is, of course, recommended technique.
> 2 - The CP wrapper that is here, CAN be used, but could end up causing more
> problems in the long run.
Well, yes and no. "Yes" in the sense that you shouldn't encourage the
kind of coding behavior that's been exhibited in the past: by writing
such a wrapper and clean-up code, you (might) encourage laziness and
make the problem worse rather than better. "No" in the sense that I
don't believe this solution is actually going to exacerbate the actual
problem itself.
Good luck,
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkr5z7AACgkQ9CaO5/Lv0PCM5ACfdA3MPnJ/YEeUwIeuNjh9akH7
2X4AoKyfvWVdOv59FJtxMrw4nyLxsrk9
=WWP3
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] ConnectionPool question
Posted by Josh Gooding <jo...@gmail.com>.
I'm glad I amuse all of you.... :P
Chris,
the reason there are multiple recycleConnection methods is because if a RS
is passed to the front presentation layer, I have to have a way to close it,
I have to be able to get the statement and connection somehow, and I don't
want that in my code.
>From everything that everyone here has said, to semi fix this right:
1 - Each method that calls the DB for a RS needs to get it's own connection
and close the resources itself (keeping it in the same scope)
2 - The CP wrapper that is here, CAN be used, but could end up causing more
problems in the long run.
Hey again, thanks for everything you all have said. I feel slightly more
confident now in fixing this conundrum. :)
- Josh
On Sat, Nov 7, 2009 at 3:17 AM, Elli Albek <el...@sustainlane.com> wrote:
> Chris, as long as we are having fun its all good. I think this
> question is something many developers ask. I have seen it here and in
> other forums.
>
> You are correct, everything is wrapped. The connection wrapper spawns
> statment wrappers which spawn result set wrappers, and everything is
> tracked in parent child relationships.
>
> E
>
> On Fri, Nov 6, 2009 at 5:54 PM, Christopher Schultz
> <ch...@christopherschultz.net> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Elli,
> >
> > Okay, I think we've hijacked Josh's thread enough to at least mark it as
> > off topic. :)
> >
> > On 11/5/2009 10:37 PM, Elli Albek wrote:
> >> Christopher Schultz wrote:
> >>> Pooled connections are almost certainly not behaving this way. This has
> >>> been discussed at least twice in the last week or two, and, I believe,
> >>> already once in this thread.
> >>
> >> This is certainly not the case for my DBCP library (1.2.2). I just
> >> stepped through the source code: Calling connection.close() is closing
> >> result sets and statements.
> >
> > I'm not sure how calling Connection.close (where the Connection object
> > is one from DBCP) would possibly be able to close ResultSet and
> > Statement objects created by the underlying connection.
> >
> > Unless, I suppose, they decided to wrap /everything/ and register all
> > the ResultSet and Statement objects handed-out by the underlying
> > Connection for the purposes of (possibly) closing them later. I should
> > really read the source :)
> >
> >> Below is the DBCP code that keeps track of open statements/result sets
> >> and closes them when the connection is closed (BDCP 1.2.2).
> >
> > Yup: it looks like they do wrap/register everything and then close it
> > for you. It's nice that they followed the spec, here :)
> >
> > - -chris
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: [OT] ConnectionPool question
Posted by Elli Albek <el...@sustainlane.com>.
Chris, as long as we are having fun its all good. I think this
question is something many developers ask. I have seen it here and in
other forums.
You are correct, everything is wrapped. The connection wrapper spawns
statment wrappers which spawn result set wrappers, and everything is
tracked in parent child relationships.
E
On Fri, Nov 6, 2009 at 5:54 PM, Christopher Schultz
<ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Elli,
>
> Okay, I think we've hijacked Josh's thread enough to at least mark it as
> off topic. :)
>
> On 11/5/2009 10:37 PM, Elli Albek wrote:
>> Christopher Schultz wrote:
>>> Pooled connections are almost certainly not behaving this way. This has
>>> been discussed at least twice in the last week or two, and, I believe,
>>> already once in this thread.
>>
>> This is certainly not the case for my DBCP library (1.2.2). I just
>> stepped through the source code: Calling connection.close() is closing
>> result sets and statements.
>
> I'm not sure how calling Connection.close (where the Connection object
> is one from DBCP) would possibly be able to close ResultSet and
> Statement objects created by the underlying connection.
>
> Unless, I suppose, they decided to wrap /everything/ and register all
> the ResultSet and Statement objects handed-out by the underlying
> Connection for the purposes of (possibly) closing them later. I should
> really read the source :)
>
>> Below is the DBCP code that keeps track of open statements/result sets
>> and closes them when the connection is closed (BDCP 1.2.2).
>
> Yup: it looks like they do wrap/register everything and then close it
> for you. It's nice that they followed the spec, here :)
>
> - -chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org