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 > >
