What I found ? was -it seems (when looking at the log) -that it is only the BMP-test that has this behavior ? ... and maybe rewriting that would solve it ? ... the result would then *only* be to hide this feature ? ... not what We want really ...
/peter_f on 1-11-29 21.57, David Maplesden at [EMAIL PROTECTED] 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
