Yes, it was Doug's change that allowed the bug to surface, but on the face of it Doug's change seems a valid one to me, when a managed connection is being deleted from a pool the underlying connection should be closed. I think Doug's change is just showing up some bad handling of the situation that was going unnoticed previously.
The problem is being caused by the fact that when the underlying connection is closed the client still has a reference to the connection wrapper, and calling createStatement on this results in a null pointer exception rather than an SQL exception. Of course the other question I was looking for an answer to is why is the connection being closed when a statement throws an exception? Does it need to be? I think there are two things here to fix. David. > -----Original Message----- > From: Scott M Stark [mailto:[EMAIL PROTECTED]] > Sent: Friday, November 30, 2001 10:41 AM > To: JBossDev (E-mail) > Subject: Re: [JBoss-dev] NPE when using DefaultDS > > > The destroy logic was just changed by thedug, so the validity > of the changes needs to be justified. I would suggest backing > out the change since it seemed to be an unthinking merge from > a 2.4 change that may have no relevance to the 3.0 codebase. > There were two changes to > jbosscx/src/main/org/jboss/resource/connectionmanager/ManagedC > onnectionPoolF > actory.java > > This needs to be rolled back to version 1.2 to undo the changes. > > ----- Original Message ----- > From: "David Maplesden" <[EMAIL PROTECTED]> > To: "JBossDev (E-mail)" <[EMAIL PROTECTED]> > Sent: Thursday, November 29, 2001 12:57 PM > Subject: RE: [JBoss-dev] NPE when using DefaultDS > > > > Ok, I have done some investigation into this and I think I am > understanding > > the problem, I'm just not too sure of the best solution. I would > appreciate > > the opinion of someone who has worked with this code before. > > > > The problem is that when a statement obtained from a given > jdbc connection > > throws a SQL exception the connection (through a rather > convoluted series > of > > method calls) is being closed. If the client program then > tries to create > > another statement using the same connection a null pointer exception > results > > because the underlying connection is returning a null, > having been closed > > already. > > > > Whether this (the connection returning null instead of > throwing another > SQL > > excpetion, which is what you would expect from a closed > connection) is > what > > should happen or not is kinda beside the point, it is what > is happening, > and > > it is happening because our resource and pooling code > decides to destroy > the > > connection when a statement from the connection throws an error. > > > > So I guess my question is why do we do this? Is there some > convention > with > > jdbc I am unaware of that suggests a connection should > become unusuable > > after a statement obtained from that connection throws an > error? Or is > > there some other good reason we are doing this? If so I > can change the > code > > so that any attempted use of the connection in this > situation will result > in > > a SQL exception rather than a NPE. > > > > If there is no particular reason we are doing this then I > will (try) to > > change the code so we don't do this! > > > > Guidence from someone who is familiar with this code would > be appreciated, > > else I am going to bang on by myself and can't guarantee > the results :-) > > > > Thanks > > David. > > > > > -----Original Message----- > > > From: Peter Fagerlund [mailto:[EMAIL PROTECTED]] > > > Sent: Wednesday, November 28, 2001 12:40 PM > > > To: David Maplesden; JBossDev (E-mail) > > > Subject: Re: [JBoss-dev] NPE when using DefaultDS > > > > > > > > > While pooking around i found and : > > > > > > Uncommented body of deleteObject(pooledObject) - line 71 of > > > > > > > org/jboss/resource/connectionmanager.ManagedConnectionPoolFactory.java > > > > > > (it seems this is called when the pool shrinks or is shut down. > > > some test -is shrinking the pool to [0/0/10] and as a effect > > > the next test > > > using the DefaultDS do not have a connection ? ... it should > > > probably create > > > one before trying to create a table ? ...) > > > > > > *** > > > > > > Now when running run-testsuite I have 169 tests running > and 1 error > > > 99.41% Success rate - heh ... > > > > > > So the xa test is failing above - We knew that - and > > > disabeling it should > > > render a cool 100% of the 169 tests ! ... > > > > > > /peter_f > > > > > > on 1-11-26 22.54, David Maplesden at > > > [EMAIL PROTECTED] wrote: > > > > > > > I have been experiencing a NPE when calling createStatement > > > on a connection > > > > obtained from DefaultDS. > > > > > > > > java.lang.NullPointerException > > > > at > > > > > > > org.jboss.resource.adapter.jdbc.local.StatementInPool.<init>(S > > > tatementInPool > > > > .java:35) > > > > at > > > > > > > org.jboss.resource.adapter.jdbc.local.ConnectionInPool.createS > > > tatement(Conne > > > > ctionInPool.java:606) > > > > > > > > This doesn't always occur and I have only noticed it in the > > > last week or so, > > > > previously it worked fine. > > > > > > > > It occurs after a previous statement throws an > > > SQLException. In other words > > > > if you are using the connections from DefaultDS everything > > > is fine until one > > > > of your SQL queries causes an SQL exception. After this > > > point you get a NPE > > > > every time you try to create another statement from a > connection for > > > > DefaultDS. > > > > > > > > I think (though I don't know for sure) that it has been > > > caused by a change > > > > to the Object pool code made last week sometime. > > > > > > > > I hope someone out there can help. > > > > > > > > Thanks > > > > David. > > > > > > > > > > > > --- > > > > Outgoing mail is certified Virus Free. > > > > Checked by AVG anti-virus system (http://www.grisoft.com). > > > > Version: 6.0.298 / Virus Database: 161 - Release Date: > 11/13/2001 > > > > > > > > > > > > _______________________________________________ > > > > Jboss-development mailing list > > > > [EMAIL PROTECTED] > > > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > > _______________________________________________ > > > Jboss-development mailing list > > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > --- > > > Incoming mail is certified Virus Free. > > > Checked by AVG anti-virus system (http://www.grisoft.com). > > > Version: 6.0.298 / Virus Database: 161 - Release Date: 11/13/2001 > > > > > > > > > > --- > > Outgoing mail is certified Virus Free. > > Checked by AVG anti-virus system (http://www.grisoft.com). > > Version: 6.0.298 / Virus Database: 161 - Release Date: 11/13/2001 > > > > > > _______________________________________________ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.298 / Virus Database: 161 - Release Date: 11/13/2001 > > --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.298 / Virus Database: 161 - Release Date: 11/13/2001 _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
