db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kathey Marsden (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1108) The test jdbcapi/setTransactionIsolation.java fails with ibm jvm1.5
Date Sun, 18 Jun 2006 15:37:37 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1108?page=comments#action_12416665 ] 

Kathey Marsden commented on DERBY-1108:

I told Manjula I would post the response from the IBM JVM Team and what I know about the issue.


I don't believe this is a bug in the IBM JVM - we are legitimately clearing out objects that
are no-longer referenced. The difference is that the IBM JVM at Java 5.0 is more agressive
at doing this than it was previously.
The behaviour with  BEA JRockit 5.0 is the same.

The IBM Java 5.0 implementation now carries out "escape analysis" - this means that an Object
becomes eligable for garbage collection after the last time it is used which can be before
you would classically expect it to be "out of scope". Below is a pathological example :

void testMethod{

	String myString = new String("MyString");
							<--- Under Java 5.0 myString is eligable for GC here
	for (int i = 0; i < 10; i++){
		System.out.println("Count is "+i);
							<-- Under previous versions, myString is eligable for GC here.

>From  the  behavior we were  seeing and the test case,  that we did not get an exception
for this open result set, when setTransactionIsolation was called,   I was under the assumption
that it was the ResultSet rs that was getting garbage collected but it must be something else.
 Someone will have to take a close look at  what is getting garbage collected here and try
to understand how it correlates to escape analysis.    I tried forcing gc() and then using
the result set and it seemed to continue to be accessible and retrieve results normally.

The test code: 

		try {
			PreparedStatement ps = conn.prepareStatement("SELECT * from TAB1");
			ResultSet rs = ps.executeQuery();
			// setTransactionIsolation should fail because we have 
			// a holdable cursor open
			// conn.setTransactionIsolation does a gc/finalization and then checks if there are open
holdable result sets.
                        // should fail because holdable result set is open.
		} catch (SQLException se)
			System.out.println("EXPECTED EXCEPTION SQLSTATE:" + 
							   se.getSQLState() + " " +

Code to check result set status in  GenericLanguageConnectionContext, called as part of setTransactionIsolation:
(Removing this gc causes setTransactionIsolation to fail as expected. )

// There may be open ResultSet's that are yet to be garbage collected
// let's try and force these out rather than throw an error


		/* For every activation */
		for (int i = acts.size() - 1; i >= 0; i--) {
			Activation a = (Activation) acts.elementAt(i);

			if (SanityManager.DEBUG)
				SanityManager.ASSERT(a instanceof CursorActivation, "a is not a CursorActivation");

			if (!a.isInUse())

			if (!a.getResultSetHoldability())

			ResultSet rs = ((CursorActivation) a).getResultSet();

			/* is there an open held result set? */
			if ((rs != null) && !rs.isClosed() && rs.returnsRows())

> 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:
>  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:
For more information on JIRA, see:

View raw message