Hi, Sunitha
This patch looks good, I successfully built and ran derbynetmats in my environment with JDK14 and JDK13.
I agree we definitely need to log a bug that the system hangs if you accidentally use "create=true" when the DB is already created -- this seems like a very possible thing to happen and I suspect many folks are still on JDK13.
David
Sunitha Kambhampati wrote:
This patch fixes derbynet/testSecMec.java test failure on 131 vms.
Problem - with 131 vms, if server and client are in the same jvm, on a second get connection with create=true attribute in the url, there is a hang.
Basically,
-- the first getConnection works ok
-- but on the second getConnection, a SQLWarning needs to be generated to say that the database already exists and in this scenario, it seems like at the point where it is creating a SQLWarning , there is a deadlock. The call to SQLWarning constructor does not return. On doing a java core dump , the thread in question seems to be in a wait state (conditional wait). Guess is it has to do with the driver manager lock
I will file a jira entry to track this issue but for the test in question, changes were made to not use create=true except for the first connection.
-- ran this test for both DerbyClient and JCC driver on both corresponding versions 131,141 ,142 on both IBM and Sun jdks. Also tested it on sun jdk 1.5.0.
-- ran derbynetmats on jdk142 ok.
-- ran derbynetclientmats on ibm131 ok.
