db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Van Couvering <da...@vancouvering.com>
Subject Re: [PATCH] change to derbynet/testSecMec.java test to fix failure on 131 vms.
Date Tue, 17 May 2005 19:05:37 GMT
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.
> 


Mime
View raw message