db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kathey Marsden (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-4334) Invoking certain methods on PreparedStatements after the underlying connection changed forces repreparing
Date Mon, 03 Aug 2009 20:31:14 GMT

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

Kathey Marsden commented on DERBY-4334:
---------------------------------------

A full assessment of methods which need the reprepare needs to be done and then a general
solution found and perhaps the DERBY-4310 fix reworked to fit into the new scheme. Maybe an
argument to getStatment() indicating whether the reprepare on changed connection is necessary.
 We also need to make sure that any state changes that are made to statements that are not
reprepared get copied over when the reprepare does occur. I think this is handled already
with the existing code, but some testing is needed to verify.

> Invoking certain methods on PreparedStatements after the underlying connection changed
forces repreparing
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-4334
>                 URL: https://issues.apache.org/jira/browse/DERBY-4334
>             Project: Derby
>          Issue Type: Bug
>          Components: JDBC
>    Affects Versions: 10.6.0.0
>            Reporter: Tiago R. Espinha
>         Attachments: ReproEmbeddedDerby4334.java, utilXid.java
>
>
> Whenever we invoke methods like isClosed() or getMetaData() on prepared or callable statements
after the underlying connection changed, these methods will try to reprepare the statement.
This becomes an issue if in the meanwhile, the query became obsolete (e.g. querying a table
that was dropped in the meanwhile).
> For example, if we start a transaction and prepare a statement with "SELECT * FROM FOO;"
then drop FOO with a parallel regular connection and try to invoke the said methods on the
statement, a repreparement will be attempted. Since FOO no longer exists, it will throw an
exception.
> I fixed this issue on DERBY-4310 for the .close() calls on Prepared and Callable statements,
but this will require more extensive work to convert the remaining methods that try to do
a getRealStatement() on the XAStatementControl. I will be attaching a repro that pops this
issue with the isClosed() call.
> The approach I used in DERBY-4310 was to add a couple of methods to XAStatementControl
that act directly on the real statement object and close them right away, without attempting
to reprepare.

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


Mime
View raw message