[
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.
JVM TEAM RESPONSE:
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");
myString.toLowercase();
System.out.println(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.
WHAT KATHEY KNOWS ABOUT THE ISSUE
>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();
rs.next();
// 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.
conn.setTransactionIsolation(java.sql.Connection.TRANSACTION_SERIALIZABLE);
} catch (SQLException se)
{
System.out.println("EXPECTED EXCEPTION SQLSTATE:" +
se.getSQLState() + "
" +
se.getMessage());
return;
}
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
System.gc();
System.runFinalization();
/* 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())
{
continue;
}
if (!a.getResultSetHoldability())
{
continue;
}
ResultSet rs = ((CursorActivation) a).getResultSet();
/* is there an open held result set? */
if ((rs != null) && !rs.isClosed() && rs.returnsRows())
{
return(false);
}
> 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
