Thanks for the excellent details. I think what's new in Java 6 is JDBC4, which includes an entirely new set of subclasses of exceptions, including SQLTransientException.
I *suspect* that this is either the new exception code that was needed to comply with JDBC4 in Derby or the new exception classes in JDBC 4 itself that are causing issues. It's odd that nobody else has hit this yet - a *lot* of people are running Derby inside J2EE containers on Java 6... David On Jan 14, 2008 2:32 PM, Johnny Kewl <[EMAIL PROTECTED]> wrote: > > > ----- Original Message ----- > From: "David Van Couvering" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]>; "Derby Discussion" <[email protected]> > Sent: Monday, January 14, 2008 10:12 PM > Subject: Fwd: [nbusers] Issues with Derby in customer classloader using Java > 6 > > > > Hi, Derby folks. John is having trouble using Derby in a custom > > classloader when running in Java 6. See the thread below. Is this a > > known issue? Any ideas why this might be happening? > > > > Thanks, > > > > David > > > > > > ---------- Forwarded message ---------- > > From: David Van Couvering <[EMAIL PROTECTED]> > > Date: Jan 14, 2008 12:08 PM > > Subject: Re: [nbusers] == I got issues with JavaDB on 6 == > > To: [EMAIL PROTECTED] > > > > > > Wow, a lot happens when you go away for the weekend :) > > > > it's really hard to track down what this issue is, and it looks like > > you may not be motivated to help us, Johnny, since you already moved > > to H2 :) > > > > I do want to clarify a few things though, just so there is no confusion: > > > > - Java DB that is embedded in JDK 6 is not used automatically when you > > use the Java 6 VM. It must be explicitly included in your classpath. > > Yes tried it both ways... I mean I really tried, even tried building derby > with different package names ;) > > I was absolutely convinced that Sun broke derby... ha ha > > > - When using Java DB embedded, you can't run into incompatibilities > > because derby.jar is a single jar file that contains everything you > > need, from the JDBC driver to the full runtime of the database > > Yes one would think so... > > > Finally, I have a question: you mention that it works fine "outside of > > a classloader" - I am having trouble picturing how a Java application > > can run outside of a classloader. Do you mean that it's using the > > default system classloader? What do you mean when it's running in a > > customer classloader? > > Yes... runiing as a normal app as apposed to say inside Tomcat... > > > > Does this problem happen outside of NetBeans or only inside NetBeans? > > If it happens outside, then this is a generic Derby/Java DB issue and > > we should report the bug with the Apache Derby community. > > Both.... but only on Java 6 > > > Thanks for any time you can spend on this Johnny, I know you've > > already moved on :) > > Damn you nice... piss off traitor would have been my choice of words... ha > ha > Only because I was deperate for a fast solution.... > > ================================================================== > This is my gut instincts talking.... > I dont think the code in Derby is broken.... but I do think its picking up > on some kind of extra "sensitivity" between Java5 and Java6 > I tried to figure out how to build a Connection Listener, because I think > one of those will demonstrate the difference. > > Let me show you some actual code from this little app > > String sSqlTable = "CREATE TABLE visitor" + > "(" + > "id integer NOT NULL," + > "name varchar(50)," + > "time_stamp timestamp DEFAULT CURRENT_TIMESTAMP," + > "CONSTRAINT visitor_pkey PRIMARY KEY (id)" + > ")"; > > dbPersistEngine.doActionQuery(sSqlTable); //If table exists will > not insert new table > dbPersistEngine.doActionQuery("CREATE INDEX visitor_id ON > visitor (id)"); //index to make dB faster > dbPersistEngine.doActionQuery("CREATE INDEX visitor_name ON > visitor (name)"); > > Now that is very very lazy code... its running a query and ignoring > exceptions.... just trapping them in the wrapper methods... > > On Java 5 it works.... on Java 6 it works under the mother ship.... > .... on Java 6 in a classloader > .... on the -> dbPersistEngine.doActionQuery("CREATE INDEX visitor_id ON > visitor (id)"); //index to make dB faster > line.... the exception will be the normal " Idiot the Index is already there > ".... but if you dig deeper with > > SQLException tmp = e; > do {//Ever since Derby stuck > in Java 6 extra issues > //This just to see what the > hell is going on > System.out.println("===="); > System.out.println("Deep > Errors: " + e.toString()); > tmp.printStackTrace(); > tmp = > tmp.getNextException(); > } while (tmp != null); > > The exception will be.... java.sql.SQLTransientConnectionException: No > current connection. > So that means everything that comes after this gets that same underlying > error..... the connection is gone. > > Now if I write slightly better code like > > try { > dbPersistEngine.doActionQueryWithException(sSqlTable); //If > table exists will not insert new table > dbPersistEngine.doActionQuery("CREATE INDEX visitor_id ON > visitor (id)"); //index to make dB faster > dbPersistEngine.doActionQuery("CREATE INDEX visitor_name ON > visitor (name)"); > } catch (SQLException ex) { > System.out.println("Table Exists " + ex.getMessage()); > } > > Then.... after that first exception it jumps over the others and it still > has a connection.... > but some lazy code somewhere else... like the user forgets to enter data and > a prepared statement tries to set this.... bang! the underlying connection > is gone. > > As you can imagine what happens then is the dB pool has actually lost a > connection and doesnt know it... so the program is really screwed. > > And thats all I can tell you.... why extra "sensitivity creeps in I dont > know".... but it does mean good or bad code that traps one too many > exceptions for > Java6... are going to make others also think Derby is screwed. > I dont know too much about the details of Java... but I have a sneaky > suspicion that if one could drop back a driver version JDBC 4 to 3 or 2 or > whatever, the sensitivity will dissapear. > > Guessing that something fancy in new error checking, automatic driver > starting, connection listening, internal pooling.... something is making > Derby tooooo sensitive. > What changed in Java6... thats the clue. > > Why this sensitivity shows itself in a custom class loader makes no sense... > unless something like a connection listener is expecting to find that info > in its classloader... and because classloaders cant look down... on the > exception, or successive exceptions it assumes the connection is gone... > > I use my own connection pools which probably makes it worse... the > connections are not sitting in a higher class loader like JNDI... they way > down in the web app class loader... if that is the case... I'm probably a > tiny tiny minority... so forget about me... ha ha > > Hope that helps.... anyway if it crops up again.... its the combination of > Derby AND Java6.... on Java 5 lazy code banging away at exceptions does not > lose the connection.... but that also could be a beeeeeg future headache. > > ... nice guy, this David chap ;) > > >> Mayuresh Nirhali > >> > >> Hi there... I did end up spending an enormous amount of time on it and > >> unfortunately I cant figure out exactly what the problem is... I will > >> gladly > >> post you the test code if you wish to examine, I could well be making a > >> mistake somewhere. It also may not be related directly to JavaDB, it may > >> well be coming from the JDBC archetecture, in Java6. > >> > >> But here are the symptoms > >> > >> + Running outside classloader... Derby Embedded works. > >> + Running inside another classloader... Derby Embedded is very sensitive > >> to > >> any exception... if that happens, the underlying dB connection is gone. > >> > >> In the identical application, if I run the H2 embedded dB or the > >> HSQLdB... > >> it works! > >> > >> This problem does not show on Java5, only on Java6 > >> > >> Thats all I can tell you... something weird is happening and it happens > >> on > >> other machines as well. > >> Its damn difficult to test because you need to build a custom class > >> loader > >> to see it happening. > >> and its intermittant... it sometimes gets through and works. > >> > >> Yes I know they the same... thats the problem, because the characteristic > >> has changed on Java6, and even if I go load Apache Derby, compile it on > >> Java > >> 5... it STILL does this on Java6... so that means working apps are > >> breaking. > >> > >> My immediate problem is solved, I moved to H2, but maybe Sun want to just > >> think about this... why would identicle software behave differently under > >> a > >> new JRE... so if JDBC has changed... the problem may be there, but I cant > >> figure it out because other embedded dB's work, but then they still maybe > >> under a slightly older JDBC version... even though I am using the latest > >> third party software.... mystery! and probably not that serious to 95% of > >> Derby users. > >> > >> It points at Derby on Java6... but nothing makes sense to me. If I could > >> get > >> another embedded java dB to do this... then it would suggest a my coding > >> problem.... it doesnt ;) > >> > >> Anyway dont worry, just make a note of it... it will probably crop up > >> again > >> as app move to Java6 > > -- David W. Van Couvering http://davidvancouvering.blogspot.com
