db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "A B (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1108) The test jdbcapi/setTransactionIsolation.java fails with ibm jvm1.5
Date Tue, 20 Jun 2006 00:02:30 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1108?page=comments#action_12416823 ] 

A B commented on DERBY-1108:
----------------------------

I'm not very well acquainted with this code, but based on the example of "escape analysis"
posted by the JVM team, I think I understand why this test is failing with IBM 1.5.

If we look at the test program again, we can see that it very closely mimics the example of
"escape analysis" offered by the JVM team.  In particular:

 		System.out.println("done creating table and inserting data.");
   		conn.setTransactionIsolation(Connection.TRANSACTION_READ_COMMITTED);
   		ResultSet rs = stmt.executeQuery("select * from T1");
==> Under Java 5.0 rs is eligible for GC here...
   		System.out.println("current isolation level: " + getIsoLevelName(conn.getTransactionIsolation()));
		conn.setTransactionIsolation(java.sql.Connection.TRANSACTION_SERIALIZABLE);
		System.out.println("current isolation level: " + getIsoLevelName(conn.getTransactionIsolation()));
==> Under previous versions, rs is eligible for GC here...

So with ibm15, rs becomes eligible for GC _prior_ to the call to setTransactionIsolation because
it (rs) is no longer referenced after it is created.  Then the call to gc() in verifyAllHeldResultSetsAreClosed()
does the escape analysis, sees that rs is now eligible for GC and so collects it.  As part
of that collection process the JVM calls "finalize()", which takes us to EmbedResultSet.finalize(),
and there we see this:

	/**
		JDBC states that a ResultSet is closed when garbage collected.
		We simply mark the activation as unused. Some later use
		of the connection will clean everything up.

		@exception Throwable Allows any exception to be thrown during finalize
	*/
	protected void finalize() throws Throwable {
		super.finalize();

		if (finalizeActivation != null) {
			finalizeActivation.markUnused();
		}		
	}

Thus finalizeActiviation is now marked as "unused", which means we end up ignoring the activation
in the verifyAllHeldResultSetsAreClosed() method:

	if (!a.isInUse())
	{
		continue;
	}

And therefore we return "true" from the method and no error is thrown.

To prove this, I added a very simple (albeit meaningless) reference to "rs" after the call
to setTransactionIsolation:

 		System.out.println("done creating table and inserting data.");
   		conn.setTransactionIsolation(Connection.TRANSACTION_READ_COMMITTED);
   		ResultSet rs = stmt.executeQuery("select * from T1");
   		System.out.println("current isolation level: " + getIsoLevelName(conn.getTransactionIsolation()));
		conn.setTransactionIsolation(java.sql.Connection.TRANSACTION_SERIALIZABLE);
		System.out.println("current isolation level: " + getIsoLevelName(conn.getTransactionIsolation()));
		System.out.println(rs);  // <== Added by Army

With this simple line, the escape analysis will *not* mark rs eligible for GC prior to setTransactionIsolation,
which means we won't call "finalize()", which means the activation will remain "in use", and
therefore we'll get the exception.

All of that said, I added System.outs to the test program to see what the object id of "rs"
is before the call to setTransactionIsolation, and I also added System.outs to see what the
object id of the "rs" is inside verifyAllHeldResultSetsAreClosed().  Not surprisingly, the
objects are NOT the same.  In the test program we see:

org.apache.derby.impl.jdbc.EmbedResultSet20@d0a0d0a

but in verifyAllHeldResultSetsAreClosed() we see:

org.apache.derby.impl.sql.execute.BulkTableScanResultSet@42484248

So as far as I can tell, the test program no longer references the EmbedResultSet, so it's
marked as "eligible for GC" and is garbage collected by escape analysis; however, that EmbedResultSet
was in turn referencing another object--BulkTableScanResultSet--that *is* still referenced
(by the activation), and that's the result set that should have caused the error--but since
we "bailed" on the error checking because the activiation was no longer "in use", we never
checked the underlying result set and therefore we didn't throw the exception.

That's my take on it after looking at it briefly.  I still don't know for sure who's "at fault"
here (the JVM or Derby)--I'd have to look at it more to say one way or the other.  But that's
my first take on the issue...

Comments/input/feedback are, as always, much appreciated...
Army

> The test jdbcapi/setTransactionIsolation.java fails with ibm jvm1.5
> -------------------------------------------------------------------
>
>          Key: DERBY-1108
>          URL: http://issues.apache.org/jira/browse/DERBY-1108
>      Project: Derby
>         Type: Bug

>   Components: Regression Test Failure
>     Versions: 10.2.0.0
>  Environment: java version "1.5.0"
> Java(TM) 2 Runtime Environment, Standard Edition (build pwi32dev-20051104)
> IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Windows XP x86-32 j9vmwi3223-2005110
> 3 (JIT enabled)
> J9VM - 20051027_03723_lHdSMR
> JIT  - 20051027_1437_r8
> GC   - 20051020_AA)
> JCL  - 20051102
>     Reporter: Manjula Kutty
>  Attachments: test.java
>
> The test  jdbcapi/setTransactionIsolation.java fails with ibmjvm15.  I think the cause
of this failure is , the jvm is not throwing an exception while trying to change the transaction
isolation when there is holdable cursor on  a resultset. Other jvms like sun jdk1.5, ibm142
throws the expected exception. while ibm15 does allow to change the transaction isolation
when there is a hold cursor on a result set.
> Already reported this issue with the ibmjvm people and they are looking in to it

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


Mime
View raw message