[
https://issues.apache.org/jira/browse/DERBY-4334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tiago R. Espinha updated DERBY-4334:
------------------------------------
Attachment: utilXid.java
ReproEmbeddedDerby4334.java
Attaching the repro.
> 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.
