db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mamta A. Satoor (JIRA)" <j...@apache.org>
Subject [jira] Reopened: (DERBY-3404) EmbedResultSet.getString() returns wrong value after auto-commit with CLOSE_CURSORS_AT_COMMIT
Date Mon, 25 Feb 2008 19:32:51 GMT

     [ https://issues.apache.org/jira/browse/DERBY-3404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Mamta A. Satoor reopened DERBY-3404:

When I try to merge the changes for this jira entry into Derby 10.3 codeline, I get "A lock
could not be obtained within the time requested" for org.apache.derbyTesting.functionTests.tests.jdbcapi.DataSourceTest.

Knut, I was wondering if you know why this might be happeneing. The specific test case I think
is testXAHoldability. If I recall it correctly, taking this test out makes the DataSourceTest
run with no errors.

> EmbedResultSet.getString() returns wrong value after auto-commit with CLOSE_CURSORS_AT_COMMIT
> ---------------------------------------------------------------------------------------------
>                 Key: DERBY-3404
>                 URL: https://issues.apache.org/jira/browse/DERBY-3404
>             Project: Derby
>          Issue Type: Bug
>    Affects Versions:,,
>            Reporter: Knut Anders Hatlen
>            Assignee: Knut Anders Hatlen
>            Priority: Minor
>             Fix For:
>         Attachments: CloseOnCommit.java, d3404-v1.diff, d3404-v1.stat
> The following code prints "null" to the console with the embedded driver:
>         Statement s = c.createStatement(ResultSet.TYPE_FORWARD_ONLY,
>                                         ResultSet.CONCUR_READ_ONLY,
>                                         ResultSet.CLOSE_CURSORS_AT_COMMIT);
>         ResultSet rs = s.executeQuery("select * from sysibm.sysdummy1");
>         rs.next();
>         c.createStatement().executeQuery("values 1").close(); // causes auto-commit
>         System.out.println(rs.getString(1));
> The call to rs.getString() should perhaps have thrown SQLException, since the auto-commit
between next() and getString() should close the ResultSet when the holdability is CLOSE_CURSORS_AT_COMMIT,
I think. Anyway, the value stored in SYSIBM.SYSDUMMY1 is 'Y' and not NULL, so it should definitely
not return null.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message