You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Kathey Marsden (JIRA)" <de...@db.apache.org> on 2006/04/19 01:34:17 UTC
[jira] Created: (DERBY-1227) Network Server should not use the
underlying embedded prepared statement when accessing a
BrokeredPreparedStatement
Network Server should not use the underlying embedded prepared statement when accessing a BrokeredPreparedStatement
-------------------------------------------------------------------------------------------------------------------
Key: DERBY-1227
URL: http://issues.apache.org/jira/browse/DERBY-1227
Project: Derby
Type: Bug
Components: Network Server
Reporter: Kathey Marsden
Priority: Minor
Fix For: 10.2.0.0
Network Server should not use the underlying embedded
Prepared statement when accessing a BrokeredPreparedStatement.
In DERBY-1025 Dan pointed out this code which while not related to DERBY-1025 does appear to be a problem. Here is his comment regarding this code in DRDAStatement:
/**
* Get prepared statement
*
* @return prepared statement
*/
protected PreparedStatement getPreparedStatement() throws SQLException
{
if (ps instanceof BrokeredPreparedStatement)
return (PreparedStatement)(
((BrokeredPreparedStatement) ps).getStatement());
else
return ps;
}
This code, for some unknown reason due to lack of comments, is getting the underlying embedded statement
from a BrokeredPreparedStatement. This should not be allowed, the BrokeredStatement wrappers are there to
hide the embedded statement object as it can change under the covers of the wrapper.
--
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
[jira] Updated: (DERBY-1227) Network Server should not use the
underlying embedded prepared statement when accessing a
BrokeredPreparedStatement
Posted by "Sunitha Kambhampati (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1227?page=all ]
Sunitha Kambhampati updated DERBY-1227:
---------------------------------------
Attachment: 10.1_p1_derby1227.diff.txt
I would like the changes related to this fix to be backported to 10.1
The changes that went into trunk are a straight merge given by the merge commands below. But there is another change required in 10.1 branch, one redundant line needs to be removed in 10.1. Note, that this line is not there in the trunk version of DRDAConnThread.
I am attaching a patch 10.1_p1_derby1227.diff.txt for this one line change in DRDAConnThread to keep this separate and simple. Only after this patch is applied, the below merge commands should be used to backport the derby1227 trunk changes.
svn merge -r 421434:421435 https://svn.apache.org/repos/asf/db/derby/code/trunk/
svn merge -r 421459:421460 https://svn.apache.org/repos/asf/db/derby/code/trunk/
10.1_p1_derby1227.diff.txt is independent of the changes that are given by the merge commands. This is a server only change. Ran derbynetclientmats and derbynetmats OK on linux/ibm142.
With 10.1_p1_derby1227.diff.txt and the merged changes, ran derbyall on linux/ibm142 OK.
Can someone please commit these changes.
Thanks,
Sunitha.
> Network Server should not use the underlying embedded prepared statement when accessing a BrokeredPreparedStatement
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1227
> URL: http://issues.apache.org/jira/browse/DERBY-1227
> Project: Derby
> Issue Type: Bug
> Components: Network Server
> Affects Versions: 10.1.2.1
> Reporter: Kathey Marsden
> Assigned To: Sunitha Kambhampati
> Fix For: 10.2.0.0
>
> Attachments: 10.1_p1_derby1227.diff.txt
>
>
> Network Server should not use the underlying embedded
> Prepared statement when accessing a BrokeredPreparedStatement.
> In DERBY-1025 Dan pointed out this code which while not related to DERBY-1025 does appear to be a problem. Here is his comment regarding this code in DRDAStatement:
> /**
> * Get prepared statement
> *
> * @return prepared statement
> */
> protected PreparedStatement getPreparedStatement() throws SQLException
> {
> if (ps instanceof BrokeredPreparedStatement)
> return (PreparedStatement)(
> ((BrokeredPreparedStatement) ps).getStatement());
> else
> return ps;
> }
> This code, for some unknown reason due to lack of comments, is getting the underlying embedded statement
> from a BrokeredPreparedStatement. This should not be allowed, the BrokeredStatement wrappers are there to
> hide the embedded statement object as it can change under the covers of the wrapper.
--
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
[jira] Commented: (DERBY-1227) Network Server should not use the
underlying embedded prepared statement when accessing a
BrokeredPreparedStatement
Posted by "Sunitha Kambhampati (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1227?page=comments#action_12419566 ]
Sunitha Kambhampati commented on DERBY-1227:
--------------------------------------------
I have been looking at this issue and the solution involves defining two new engine interfaces for use in the server. There is DERBY-1015 which talks about defining the engine interfaces for use in network server. I have attached a patch derby1015.diff.txt for feedback. I'd appreciate it if someone could review the changes. Thanks.
> Network Server should not use the underlying embedded prepared statement when accessing a BrokeredPreparedStatement
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1227
> URL: http://issues.apache.org/jira/browse/DERBY-1227
> Project: Derby
> Type: Bug
> Components: Network Server
> Versions: 10.1.2.1
> Reporter: Kathey Marsden
> Assignee: Sunitha Kambhampati
> Fix For: 10.2.0.0
>
> Network Server should not use the underlying embedded
> Prepared statement when accessing a BrokeredPreparedStatement.
> In DERBY-1025 Dan pointed out this code which while not related to DERBY-1025 does appear to be a problem. Here is his comment regarding this code in DRDAStatement:
> /**
> * Get prepared statement
> *
> * @return prepared statement
> */
> protected PreparedStatement getPreparedStatement() throws SQLException
> {
> if (ps instanceof BrokeredPreparedStatement)
> return (PreparedStatement)(
> ((BrokeredPreparedStatement) ps).getStatement());
> else
> return ps;
> }
> This code, for some unknown reason due to lack of comments, is getting the underlying embedded statement
> from a BrokeredPreparedStatement. This should not be allowed, the BrokeredStatement wrappers are there to
> hide the embedded statement object as it can change under the covers of the wrapper.
--
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
[jira] Commented: (DERBY-1227) Network Server should not use the
underlying embedded prepared statement when accessing a
BrokeredPreparedStatement
Posted by "Sunitha Kambhampati (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1227?page=comments#action_12422765 ]
Sunitha Kambhampati commented on DERBY-1227:
--------------------------------------------
Thanks Mike into looking at this. Here is the checkin comment:
-------------------------------------------------------------------------------------------------------------------------------------
DERBY-1227 Network Server should not use the underlying embedded prepared statement when accessing a BrokeredPreparedStatement
-- Added new interfaces EnginePreparedStatement and EngineParameterMetaData for use in network server.
-- Made changes to server code to use these interfaces and thus have a consistent way of handling the PreparedStatement whether it is a EmbedPreparedStatement or BrokeredPreparedStatement.
Backport from trunk, the original changes went as part of DERBY-1015.
svn merge -r 421434:421435 https://svn.apache.org/repos/asf/db/derby/code/trunk/
svn merge -r 421459:421460 https://svn.apache.org/repos/asf/db/derby/code/trunk/
-------------------------------------------------------------------------------------------------------------------------------------
> Network Server should not use the underlying embedded prepared statement when accessing a BrokeredPreparedStatement
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1227
> URL: http://issues.apache.org/jira/browse/DERBY-1227
> Project: Derby
> Issue Type: Bug
> Components: Network Server
> Affects Versions: 10.1.2.1
> Reporter: Kathey Marsden
> Assigned To: Sunitha Kambhampati
> Fix For: 10.2.0.0
>
> Attachments: 10.1_p1_derby1227.diff.txt
>
>
> Network Server should not use the underlying embedded
> Prepared statement when accessing a BrokeredPreparedStatement.
> In DERBY-1025 Dan pointed out this code which while not related to DERBY-1025 does appear to be a problem. Here is his comment regarding this code in DRDAStatement:
> /**
> * Get prepared statement
> *
> * @return prepared statement
> */
> protected PreparedStatement getPreparedStatement() throws SQLException
> {
> if (ps instanceof BrokeredPreparedStatement)
> return (PreparedStatement)(
> ((BrokeredPreparedStatement) ps).getStatement());
> else
> return ps;
> }
> This code, for some unknown reason due to lack of comments, is getting the underlying embedded statement
> from a BrokeredPreparedStatement. This should not be allowed, the BrokeredStatement wrappers are there to
> hide the embedded statement object as it can change under the covers of the wrapper.
--
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
[jira] Resolved: (DERBY-1227) Network Server should not use the
underlying embedded prepared statement when accessing a
BrokeredPreparedStatement
Posted by "Sunitha Kambhampati (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1227?page=all ]
Sunitha Kambhampati resolved DERBY-1227.
----------------------------------------
Resolution: Fixed
This issue is fixed with the changes I made for DERBY-1015 , derby1015.diff.txt. The changes have been checked into trunk.
URL: http://svn.apache.org/viewvc?rev=421435&view=rev
URL: http://svn.apache.org/viewvc?rev=421460&view=rev
> Network Server should not use the underlying embedded prepared statement when accessing a BrokeredPreparedStatement
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1227
> URL: http://issues.apache.org/jira/browse/DERBY-1227
> Project: Derby
> Issue Type: Bug
> Components: Network Server
> Affects Versions: 10.1.2.1
> Reporter: Kathey Marsden
> Assigned To: Sunitha Kambhampati
> Fix For: 10.2.0.0
>
>
> Network Server should not use the underlying embedded
> Prepared statement when accessing a BrokeredPreparedStatement.
> In DERBY-1025 Dan pointed out this code which while not related to DERBY-1025 does appear to be a problem. Here is his comment regarding this code in DRDAStatement:
> /**
> * Get prepared statement
> *
> * @return prepared statement
> */
> protected PreparedStatement getPreparedStatement() throws SQLException
> {
> if (ps instanceof BrokeredPreparedStatement)
> return (PreparedStatement)(
> ((BrokeredPreparedStatement) ps).getStatement());
> else
> return ps;
> }
> This code, for some unknown reason due to lack of comments, is getting the underlying embedded statement
> from a BrokeredPreparedStatement. This should not be allowed, the BrokeredStatement wrappers are there to
> hide the embedded statement object as it can change under the covers of the wrapper.
--
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
[jira] Updated: (DERBY-1227) Network Server should not use the
underlying embedded prepared statement when accessing a
BrokeredPreparedStatement
Posted by "Mike Matrigali (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1227?page=all ]
Mike Matrigali updated DERBY-1227:
----------------------------------
I will look at committing the backport to 10.1
> Network Server should not use the underlying embedded prepared statement when accessing a BrokeredPreparedStatement
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1227
> URL: http://issues.apache.org/jira/browse/DERBY-1227
> Project: Derby
> Issue Type: Bug
> Components: Network Server
> Affects Versions: 10.1.2.1
> Reporter: Kathey Marsden
> Assigned To: Sunitha Kambhampati
> Fix For: 10.2.0.0
>
> Attachments: 10.1_p1_derby1227.diff.txt
>
>
> Network Server should not use the underlying embedded
> Prepared statement when accessing a BrokeredPreparedStatement.
> In DERBY-1025 Dan pointed out this code which while not related to DERBY-1025 does appear to be a problem. Here is his comment regarding this code in DRDAStatement:
> /**
> * Get prepared statement
> *
> * @return prepared statement
> */
> protected PreparedStatement getPreparedStatement() throws SQLException
> {
> if (ps instanceof BrokeredPreparedStatement)
> return (PreparedStatement)(
> ((BrokeredPreparedStatement) ps).getStatement());
> else
> return ps;
> }
> This code, for some unknown reason due to lack of comments, is getting the underlying embedded statement
> from a BrokeredPreparedStatement. This should not be allowed, the BrokeredStatement wrappers are there to
> hide the embedded statement object as it can change under the covers of the wrapper.
--
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
[jira] Assigned: (DERBY-1227) Network Server should not use the
underlying embedded prepared statement when accessing a
BrokeredPreparedStatement
Posted by "Sunitha Kambhampati (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1227?page=all ]
Sunitha Kambhampati reassigned DERBY-1227:
------------------------------------------
Assign To: Sunitha Kambhampati
> Network Server should not use the underlying embedded prepared statement when accessing a BrokeredPreparedStatement
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1227
> URL: http://issues.apache.org/jira/browse/DERBY-1227
> Project: Derby
> Type: Bug
> Components: Network Server
> Versions: 10.1.2.1
> Reporter: Kathey Marsden
> Assignee: Sunitha Kambhampati
> Fix For: 10.2.0.0
>
> Network Server should not use the underlying embedded
> Prepared statement when accessing a BrokeredPreparedStatement.
> In DERBY-1025 Dan pointed out this code which while not related to DERBY-1025 does appear to be a problem. Here is his comment regarding this code in DRDAStatement:
> /**
> * Get prepared statement
> *
> * @return prepared statement
> */
> protected PreparedStatement getPreparedStatement() throws SQLException
> {
> if (ps instanceof BrokeredPreparedStatement)
> return (PreparedStatement)(
> ((BrokeredPreparedStatement) ps).getStatement());
> else
> return ps;
> }
> This code, for some unknown reason due to lack of comments, is getting the underlying embedded statement
> from a BrokeredPreparedStatement. This should not be allowed, the BrokeredStatement wrappers are there to
> hide the embedded statement object as it can change under the covers of the wrapper.
--
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
[jira] Updated: (DERBY-1227) Network Server should not use the
underlying embedded prepared statement when accessing a
BrokeredPreparedStatement
Posted by "Kathey Marsden (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1227?page=all ]
Kathey Marsden updated DERBY-1227:
----------------------------------
Priority: Major (was: Minor)
Rasing this to major. Dan had indicated that this could cause the wrong statement to be returned and unexpected and upredictable behavior, so may be serious.
> Network Server should not use the underlying embedded prepared statement when accessing a BrokeredPreparedStatement
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1227
> URL: http://issues.apache.org/jira/browse/DERBY-1227
> Project: Derby
> Type: Bug
> Components: Network Server
> Versions: 10.1.2.1
> Reporter: Kathey Marsden
> Fix For: 10.2.0.0
>
> Network Server should not use the underlying embedded
> Prepared statement when accessing a BrokeredPreparedStatement.
> In DERBY-1025 Dan pointed out this code which while not related to DERBY-1025 does appear to be a problem. Here is his comment regarding this code in DRDAStatement:
> /**
> * Get prepared statement
> *
> * @return prepared statement
> */
> protected PreparedStatement getPreparedStatement() throws SQLException
> {
> if (ps instanceof BrokeredPreparedStatement)
> return (PreparedStatement)(
> ((BrokeredPreparedStatement) ps).getStatement());
> else
> return ps;
> }
> This code, for some unknown reason due to lack of comments, is getting the underlying embedded statement
> from a BrokeredPreparedStatement. This should not be allowed, the BrokeredStatement wrappers are there to
> hide the embedded statement object as it can change under the covers of the wrapper.
--
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
[jira] Updated: (DERBY-1227) Network Server should not use the
underlying embedded prepared statement when accessing a
BrokeredPreparedStatement
Posted by "Sunitha Kambhampati (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1227?page=all ]
Sunitha Kambhampati updated DERBY-1227:
---------------------------------------
Derby Info: [Patch Available]
> Network Server should not use the underlying embedded prepared statement when accessing a BrokeredPreparedStatement
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1227
> URL: http://issues.apache.org/jira/browse/DERBY-1227
> Project: Derby
> Issue Type: Bug
> Components: Network Server
> Affects Versions: 10.1.2.1
> Reporter: Kathey Marsden
> Assigned To: Sunitha Kambhampati
> Fix For: 10.2.0.0
>
> Attachments: 10.1_p1_derby1227.diff.txt
>
>
> Network Server should not use the underlying embedded
> Prepared statement when accessing a BrokeredPreparedStatement.
> In DERBY-1025 Dan pointed out this code which while not related to DERBY-1025 does appear to be a problem. Here is his comment regarding this code in DRDAStatement:
> /**
> * Get prepared statement
> *
> * @return prepared statement
> */
> protected PreparedStatement getPreparedStatement() throws SQLException
> {
> if (ps instanceof BrokeredPreparedStatement)
> return (PreparedStatement)(
> ((BrokeredPreparedStatement) ps).getStatement());
> else
> return ps;
> }
> This code, for some unknown reason due to lack of comments, is getting the underlying embedded statement
> from a BrokeredPreparedStatement. This should not be allowed, the BrokeredStatement wrappers are there to
> hide the embedded statement object as it can change under the covers of the wrapper.
--
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
[jira] Closed: (DERBY-1227) Network Server should not use the
underlying embedded prepared statement when accessing a
BrokeredPreparedStatement
Posted by "Sunitha Kambhampati (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1227?page=all ]
Sunitha Kambhampati closed DERBY-1227.
--------------------------------------
Ran tests and verified the fix is in 10.1 as well as 10.2, so closing this issue.
> Network Server should not use the underlying embedded prepared statement when accessing a BrokeredPreparedStatement
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1227
> URL: http://issues.apache.org/jira/browse/DERBY-1227
> Project: Derby
> Issue Type: Bug
> Components: Network Server
> Affects Versions: 10.1.2.1
> Reporter: Kathey Marsden
> Assigned To: Sunitha Kambhampati
> Fix For: 10.2.0.0, 10.1.4.0
>
> Attachments: 10.1_p1_derby1227.diff.txt
>
>
> Network Server should not use the underlying embedded
> Prepared statement when accessing a BrokeredPreparedStatement.
> In DERBY-1025 Dan pointed out this code which while not related to DERBY-1025 does appear to be a problem. Here is his comment regarding this code in DRDAStatement:
> /**
> * Get prepared statement
> *
> * @return prepared statement
> */
> protected PreparedStatement getPreparedStatement() throws SQLException
> {
> if (ps instanceof BrokeredPreparedStatement)
> return (PreparedStatement)(
> ((BrokeredPreparedStatement) ps).getStatement());
> else
> return ps;
> }
> This code, for some unknown reason due to lack of comments, is getting the underlying embedded statement
> from a BrokeredPreparedStatement. This should not be allowed, the BrokeredStatement wrappers are there to
> hide the embedded statement object as it can change under the covers of the wrapper.
--
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
[jira] Commented: (DERBY-1227) Network Server should not use the
underlying embedded prepared statement when accessing a
BrokeredPreparedStatement
Posted by "Kathey Marsden (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1227?page=comments#action_12412828 ]
Kathey Marsden commented on DERBY-1227:
---------------------------------------
Mike asked me to post what I know about this issue, which isn't alot but perhaps might be a starting point.
THE IMPACT:
Dan had mentioned that this might cause the wrong statement to be returned and so could be potentially serious and hard to diagnose in the field.
THE PROBLEM:
I think there are reflection calls for prepared statements for methods that are not avable in BrokeredPreparedStatements: e.g.
Method sh =
getPreparedStatement().getClass().getMethod("getEmbedParameterSetMetaData", getParameterMetaDataParam);
THE FIX:
One possible fix might be to implement an org.apache.derby.iapi.jdbc.EnginePreparedStatement interface similar to EngineConnection that will allow exposure of these methods and allow consistant interaction between EmbedPreparedStatements and BrokeredPreparedStatements.
See org.apache.derby.iapi.jdbc.EngineConnection for a more information.
> Network Server should not use the underlying embedded prepared statement when accessing a BrokeredPreparedStatement
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1227
> URL: http://issues.apache.org/jira/browse/DERBY-1227
> Project: Derby
> Type: Bug
> Components: Network Server
> Reporter: Kathey Marsden
> Priority: Minor
> Fix For: 10.2.0.0
>
> Network Server should not use the underlying embedded
> Prepared statement when accessing a BrokeredPreparedStatement.
> In DERBY-1025 Dan pointed out this code which while not related to DERBY-1025 does appear to be a problem. Here is his comment regarding this code in DRDAStatement:
> /**
> * Get prepared statement
> *
> * @return prepared statement
> */
> protected PreparedStatement getPreparedStatement() throws SQLException
> {
> if (ps instanceof BrokeredPreparedStatement)
> return (PreparedStatement)(
> ((BrokeredPreparedStatement) ps).getStatement());
> else
> return ps;
> }
> This code, for some unknown reason due to lack of comments, is getting the underlying embedded statement
> from a BrokeredPreparedStatement. This should not be allowed, the BrokeredStatement wrappers are there to
> hide the embedded statement object as it can change under the covers of the wrapper.
--
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
[jira] Updated: (DERBY-1227) Network Server should not use the
underlying embedded prepared statement when accessing a
BrokeredPreparedStatement
Posted by "Kathey Marsden (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1227?page=all ]
Kathey Marsden updated DERBY-1227:
----------------------------------
Version: 10.1.2.1
> Network Server should not use the underlying embedded prepared statement when accessing a BrokeredPreparedStatement
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1227
> URL: http://issues.apache.org/jira/browse/DERBY-1227
> Project: Derby
> Type: Bug
> Components: Network Server
> Versions: 10.1.2.1
> Reporter: Kathey Marsden
> Fix For: 10.2.0.0
>
> Network Server should not use the underlying embedded
> Prepared statement when accessing a BrokeredPreparedStatement.
> In DERBY-1025 Dan pointed out this code which while not related to DERBY-1025 does appear to be a problem. Here is his comment regarding this code in DRDAStatement:
> /**
> * Get prepared statement
> *
> * @return prepared statement
> */
> protected PreparedStatement getPreparedStatement() throws SQLException
> {
> if (ps instanceof BrokeredPreparedStatement)
> return (PreparedStatement)(
> ((BrokeredPreparedStatement) ps).getStatement());
> else
> return ps;
> }
> This code, for some unknown reason due to lack of comments, is getting the underlying embedded statement
> from a BrokeredPreparedStatement. This should not be allowed, the BrokeredStatement wrappers are there to
> hide the embedded statement object as it can change under the covers of the wrapper.
--
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
[jira] Updated: (DERBY-1227) Network Server should not use the
underlying embedded prepared statement when accessing a
BrokeredPreparedStatement
Posted by "Mike Matrigali (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1227?page=all ]
Mike Matrigali updated DERBY-1227:
----------------------------------
Fix Version/s: 10.1.4.0
committed patch to 10.1 branch:
m101_142:117>svn commit
Sending java\drda\org\apache\derby\impl\drda\DRDAConnThread.java
Sending java\drda\org\apache\derby\impl\drda\DRDAStatement.java
Sending java\engine\org\apache\derby\iapi\jdbc\BrokeredPreparedStatement.java
Adding java\engine\org\apache\derby\iapi\jdbc\EngineParameterMetaData.java
Adding java\engine\org\apache\derby\iapi\jdbc\EnginePreparedStatement.java
Sending java\engine\org\apache\derby\impl\jdbc\EmbedParameterSetMetaData.java
Sending java\engine\org\apache\derby\impl\jdbc\EmbedPreparedStatement.java
Transmitting file data .......
Committed revision 424451.
> Network Server should not use the underlying embedded prepared statement when accessing a BrokeredPreparedStatement
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1227
> URL: http://issues.apache.org/jira/browse/DERBY-1227
> Project: Derby
> Issue Type: Bug
> Components: Network Server
> Affects Versions: 10.1.2.1
> Reporter: Kathey Marsden
> Assigned To: Sunitha Kambhampati
> Fix For: 10.2.0.0, 10.1.4.0
>
> Attachments: 10.1_p1_derby1227.diff.txt
>
>
> Network Server should not use the underlying embedded
> Prepared statement when accessing a BrokeredPreparedStatement.
> In DERBY-1025 Dan pointed out this code which while not related to DERBY-1025 does appear to be a problem. Here is his comment regarding this code in DRDAStatement:
> /**
> * Get prepared statement
> *
> * @return prepared statement
> */
> protected PreparedStatement getPreparedStatement() throws SQLException
> {
> if (ps instanceof BrokeredPreparedStatement)
> return (PreparedStatement)(
> ((BrokeredPreparedStatement) ps).getStatement());
> else
> return ps;
> }
> This code, for some unknown reason due to lack of comments, is getting the underlying embedded statement
> from a BrokeredPreparedStatement. This should not be allowed, the BrokeredStatement wrappers are there to
> hide the embedded statement object as it can change under the covers of the wrapper.
--
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
[jira] Commented: (DERBY-1227) Network Server should not use the
underlying embedded prepared statement when accessing a
BrokeredPreparedStatement
Posted by "Sunitha Kambhampati (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1227?page=comments#action_12422505 ]
Sunitha Kambhampati commented on DERBY-1227:
--------------------------------------------
After applying the patch and the merge command to backport to 10.1, here is the svn stat info:
M java\engine\org\apache\derby\impl\jdbc\EmbedPreparedStatement.java
M java\engine\org\apache\derby\impl\jdbc\EmbedParameterSetMetaData.java
M java\engine\org\apache\derby\iapi\jdbc\BrokeredPreparedStatement.java
A + java\engine\org\apache\derby\iapi\jdbc\EngineParameterMetaData.java
A + java\engine\org\apache\derby\iapi\jdbc\EnginePreparedStatement.java
M java\drda\org\apache\derby\impl\drda\DRDAStatement.java
M java\drda\org\apache\derby\impl\drda\DRDAConnThread.java
> Network Server should not use the underlying embedded prepared statement when accessing a BrokeredPreparedStatement
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1227
> URL: http://issues.apache.org/jira/browse/DERBY-1227
> Project: Derby
> Issue Type: Bug
> Components: Network Server
> Affects Versions: 10.1.2.1
> Reporter: Kathey Marsden
> Assigned To: Sunitha Kambhampati
> Fix For: 10.2.0.0
>
> Attachments: 10.1_p1_derby1227.diff.txt
>
>
> Network Server should not use the underlying embedded
> Prepared statement when accessing a BrokeredPreparedStatement.
> In DERBY-1025 Dan pointed out this code which while not related to DERBY-1025 does appear to be a problem. Here is his comment regarding this code in DRDAStatement:
> /**
> * Get prepared statement
> *
> * @return prepared statement
> */
> protected PreparedStatement getPreparedStatement() throws SQLException
> {
> if (ps instanceof BrokeredPreparedStatement)
> return (PreparedStatement)(
> ((BrokeredPreparedStatement) ps).getStatement());
> else
> return ps;
> }
> This code, for some unknown reason due to lack of comments, is getting the underlying embedded statement
> from a BrokeredPreparedStatement. This should not be allowed, the BrokeredStatement wrappers are there to
> hide the embedded statement object as it can change under the covers of the wrapper.
--
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