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 <e...@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-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Reply via email to