I don't know if you do have to distinguish between fatal and non-fatal errors though. If the error was fatal then the next time the underlying connection is accessed then it will indicate this by throwing a SQL exception of its own.
I guess this is not ideal as you want to avoid returning a bad connection to the pool, but we have no indication that the connection is bad, simply because a statement threw an exception. I think we wait until a connection throws an exception of its own before we declare it as bad. David > -----Original Message----- > From: David Jencks [mailto:[EMAIL PROTECTED]] > Sent: Friday, November 30, 2001 10:57 AM > To: David Maplesden > Cc: JBossDev > Subject: Re: [JBoss-dev] NPE when using DefaultDS > > > You probably now know more about this is implemented than > anyone else at > the moment ;-). I haven't looked at this for a while but I think the > following is more or less accurate. > > The problem IMHO is deciding when a fatal error has occured. > When it has, > the ConnectionManager is supposed to call > ManagedConnection.destroy and > remove the ManagedConnection from the pool. > > I think perhaps Doug's recent changes had something to do > with this: when > the connection dies, you definitely want to ditch the > ManagedConnection. > > However, if you just try to execute some invalid sql, > everything is still > fine. > > I haven't looked into sorting SQLExceptions lately. Is there > a reasonable > way to distinguish fatal from non-fatal exceptions? > > david jencks > > On 2001.11.29 15:57:37 -0500 David Maplesden wrote: > > 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 > > > > > > _______________________________________________ > 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
