db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5459) Result set metadata are out of sync on client after underlying table is altered
Date Fri, 14 Oct 2011 06:14:11 GMT

    [ https://issues.apache.org/jira/browse/DERBY-5459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13127290#comment-13127290

Dag H. Wanvik commented on DERBY-5459:

>From looking at the code in client PreparedStatement#getMetaData, which calls getMetadataX,
there is no attempt to verify that the prepared statement's metadata is still up-to-date.
Repreparing the ps does bring it up to date, though. Perhaps we should just disabled this
caching and reprepare whenever PreparedStatement#getMetaData is called. On the server this
will not necessarily lead to a recompilation, of course. It does, however, incur a client
server round-trip, but since we don't have any push service, I think polling is the only way
to get the correct behavior. 

But it doesn't stop there: if we (re)execute the prepared statement (for which the cached
metadata on the client is out of date), a new result set resulting from a query using that
ps will inherit the stale metadata from the ps, cf. Statement#completeOpenQuery ca line 1493:

          resultSet.resultSetMetaData_ = resultSetMetaData_;

so  the metadata for the newly retrieved result set will also be stale (since the execution
doesn't presently signal that the metadata has changed in any way). Thinking aloud, maybe
we could version the metadata and attach the version number to the query result. If the cached
version were out of date the client would need to retrieve the result set's metadata before
closing the result set (so it would be guaranteed to be correct: the server does keep the
info as long as the rs is open I think).
> Result set metadata are out of sync on client after underlying table is altered
> -------------------------------------------------------------------------------
>                 Key: DERBY-5459
>                 URL: https://issues.apache.org/jira/browse/DERBY-5459
>             Project: Derby
>          Issue Type: Bug
>          Components: JDBC
>    Affects Versions:,,,,,,,,,,,,,
>            Reporter: Dag H. Wanvik
>         Attachments: Repro.java, repro-patch.diff
> Cf the discussion on DERBY-3823.
> The enclosed repro program shows what happens. When I run it with
> client/server and embedded respectively we see these two differing
> results:
> client/server:
> $ java -cp .:$CLASSPATH Repo
> Done loading data
> executing alter
> execp.getResultDescription: select * from t1
> 2. PS#getMetaData: char column length is 8
> Reexecuting ps on changed table...
> 3. RS#getMetadata: char column length is 8
> data:1 12345678
> dag@T61pOS:~/java/sb/apps/derby3823$ !rm
> rm -rf DERBY3823DB
> embedded:
> dag@T61pOS:~/java/sb/apps/derby3823$ java -cp .:$CLASSPATH Repro 2
> execp.getResultDescription: insert into t1 values(?,'aaaaa')
> execp.getResultDescription: insert into t1 values(?,'aaaaa')
> Done loading data
> execp.getResultDescription: select * from t1
> execp.getResultDescription: select * from t1
> executing alter
> 2. PS#getMetaData: char column length is 5
> Reexecuting ps on changed tableh...
> 3. RS#getMetadata: char column length is 5
> data:1 12345678
> As we can see, the metadata results are different after the ALTER
> TABLE. The trace from EmbedPreparedData
> ("execp.getResultDescription:") lines (see repro-patch.diff) show that
> after ALTER, the metadata are not refreshed on the server side.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message