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)" <ji...@apache.org> on 2010/05/19 01:56:56 UTC
[jira] Created: (DERBY-4664) Change Derby internal stored
procedures to avoid DriverManager.getConnection("jdbc:default:connection")
as it may be recognized by other Drivers
Change Derby internal stored procedures to avoid DriverManager.getConnection("jdbc:default:connection") as it may be recognized by other Drivers
------------------------------------------------------------------------------------------------------------------------------------------------
Key: DERBY-4664
URL: https://issues.apache.org/jira/browse/DERBY-4664
Project: Derby
Issue Type: Bug
Affects Versions: 10.6.1.0, 10.5.3.0, 10.4.2.0, 10.3.3.0, 10.2.2.0, 10.1.3.1
Reporter: Kathey Marsden
Fix For: 10.3.3.1, 10.4.2.1, 10.5.3.1, 10.6.1.1
Some Derby internal Stored procedures and functions call DriverManager.getConnection("jdbc:default:connection"); and this url can be recognized by another Driver in the same classpath that is used for server side JDBC for another product. For example the below occurred in NetworkServer when JCC was also loaded because the JCC Type 2 driver is used for server side JDBC:
java.lang.UnsatisfiedLinkError:
db2jcct2 (Not found in java.library.path): ERRORCODE=-4472, SQLSTATE=null
com.ibm.db2.jcc.b.SqlException
at com.ibm.db2.jcc.b.bd.a(bd.java:660)
at com.ibm.db2.jcc.b.bd.a(bd.java:60)
at com.ibm.db2.jcc.b.bd.a(bd.java:94)
at com.ibm.db2.jcc.t2.a.a(a.java:37)
at com.ibm.db2.jcc.t2.T2Configuration.<clinit>(T2Configuration.java:94)
at java.lang.J9VMInternals.initializeImpl(Native Method)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:196)
at com.ibm.db2.jcc.DB2Driver.connect(DB2Driver.java:211)
at java.sql.DriverManager.getConnection(DriverManager.java:572)
at java.sql.DriverManager.getConnection(DriverManager.java:218)
at org.apache.derby.impl.jdbc.LOBStoredProcedure.getEmbedConnection(Unknown Source)
at org.apache.derby.impl.jdbc.LOBStoredProcedure.getClobObjectCorrespondingtoLOCATOR(Unknown Source)
at org.apache.derby.impl.jdbc.LOBStoredProcedure.CLOBGETLENGTH(Unknown Source)
at org.apache.derby.exe.acf81e0010x0128x864dxbe82x00004c9b380d12.e0(Unknown Source)
at org.apache.derby.impl.services.reflect.DirectCall.invoke(Unknown Source)
at org.apache.derby.impl.sql.execute.RowResultSet.getNextRowCore(Unknown Source)
at org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.getNextRow(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedResultSet.movePosition(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedResultSet.next(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedCallableStatement.executeStatement(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(Unknown Source)
at org.apache.derby.impl.drda.DRDAStatement.execute(Unknown Source)
at org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLSTTobjects(Unknown Source)
at org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLSTT(Unknown Source)
at org.apache.derby.impl.drda.DRDAConnThread.processCommands(Unknown Source)
at org.apache.derby.impl.drda.DRDAConnThread.run(Unknown Source)
I think we can avoid this specific error by changing LobStoredProcedure (and perhaps other internal procedures) to use the code in SystemProcedures.getDefaultConn() which always connects to Derby by using = InternalDriver.activeDriver()
This of course will not solve the general problem for any user created procedure or function that performs SQL. I am not sure if there is a good solution for that. I asked the JCC Driver team to see if there is a way they can determine if they are running inside the DB2 process or not. but regardless of these product workarounds I think the basic problem is design flaw in the specification. DriverManager cannot differentiate the URL if all database products use the same one for server side JDBC.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-4664) Change Derby internal stored
procedures to avoid DriverManager.getConnection("jdbc:default:connection")
as it may be recognized by other Drivers
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kathey Marsden resolved DERBY-4664.
-----------------------------------
Assignee: Kathey Marsden
Fix Version/s: 10.7.0.0
Resolution: Fixed
Fix checked into trunk and all branches back to 10.3. It looks like LOBStoredProcedure was not present in earlier releases so no need to go back further.
> Change Derby internal stored procedures to avoid DriverManager.getConnection("jdbc:default:connection") as it may be recognized by other Drivers
> ------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4664
> URL: https://issues.apache.org/jira/browse/DERBY-4664
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.1.3.1, 10.2.2.0, 10.3.3.0, 10.4.2.0, 10.5.3.0, 10.6.1.0
> Reporter: Kathey Marsden
> Assignee: Kathey Marsden
> Fix For: 10.3.3.1, 10.4.2.1, 10.5.3.1, 10.6.1.1, 10.7.0.0
>
> Attachments: derby-4664_diff.txt
>
>
> Some Derby internal Stored procedures and functions call DriverManager.getConnection("jdbc:default:connection"); and this url can be recognized by another Driver in the same classpath that is used for server side JDBC for another product. For example the below occurred in NetworkServer when JCC was also loaded because the JCC Type 2 driver is used for server side JDBC:
> java.lang.UnsatisfiedLinkError:
> db2jcct2 (Not found in java.library.path): ERRORCODE=-4472, SQLSTATE=null
> com.ibm.db2.jcc.b.SqlException
> at com.ibm.db2.jcc.b.bd.a(bd.java:660)
> at com.ibm.db2.jcc.b.bd.a(bd.java:60)
> at com.ibm.db2.jcc.b.bd.a(bd.java:94)
> at com.ibm.db2.jcc.t2.a.a(a.java:37)
> at com.ibm.db2.jcc.t2.T2Configuration.<clinit>(T2Configuration.java:94)
> at java.lang.J9VMInternals.initializeImpl(Native Method)
> at java.lang.J9VMInternals.initialize(J9VMInternals.java:196)
> at com.ibm.db2.jcc.DB2Driver.connect(DB2Driver.java:211)
> at java.sql.DriverManager.getConnection(DriverManager.java:572)
> at java.sql.DriverManager.getConnection(DriverManager.java:218)
> at org.apache.derby.impl.jdbc.LOBStoredProcedure.getEmbedConnection(Unknown Source)
> at org.apache.derby.impl.jdbc.LOBStoredProcedure.getClobObjectCorrespondingtoLOCATOR(Unknown Source)
> at org.apache.derby.impl.jdbc.LOBStoredProcedure.CLOBGETLENGTH(Unknown Source)
> at org.apache.derby.exe.acf81e0010x0128x864dxbe82x00004c9b380d12.e0(Unknown Source)
> at org.apache.derby.impl.services.reflect.DirectCall.invoke(Unknown Source)
> at org.apache.derby.impl.sql.execute.RowResultSet.getNextRowCore(Unknown Source)
> at org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.getNextRow(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedResultSet.movePosition(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedResultSet.next(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedCallableStatement.executeStatement(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(Unknown Source)
> at org.apache.derby.impl.drda.DRDAStatement.execute(Unknown Source)
> at org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLSTTobjects(Unknown Source)
> at org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLSTT(Unknown Source)
> at org.apache.derby.impl.drda.DRDAConnThread.processCommands(Unknown Source)
> at org.apache.derby.impl.drda.DRDAConnThread.run(Unknown Source)
> I think we can avoid this specific error by changing LobStoredProcedure (and perhaps other internal procedures) to use the code in SystemProcedures.getDefaultConn() which always connects to Derby by using = InternalDriver.activeDriver()
> This of course will not solve the general problem for any user created procedure or function that performs SQL. I am not sure if there is a good solution for that. I asked the JCC Driver team to see if there is a way they can determine if they are running inside the DB2 process or not. but regardless of these product workarounds I think the basic problem is design flaw in the specification. DriverManager cannot differentiate the URL if all database products use the same one for server side JDBC.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-4664) Change Derby internal stored
procedures to avoid DriverManager.getConnection("jdbc:default:connection")
as it may be recognized by other Drivers
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kathey Marsden updated DERBY-4664:
----------------------------------
Attachment: derby-4664_diff.txt
Attached is a patch which fixes the internal procedures in LobStoredProcedures . I could not find any Derby internal procedures that use DriverManager with jdbc:default:connection.
This fix does not solve the general issue of JCC hijacking the derby stored procedure connection for user procedures, but at least the internal procedures should not encounter the problem which I could reproduce simply by adding db2jcc4.jar (JCC 4.1) to my classpath and running the test jdbcapi.ClobStoredProcedureTest.
> Change Derby internal stored procedures to avoid DriverManager.getConnection("jdbc:default:connection") as it may be recognized by other Drivers
> ------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4664
> URL: https://issues.apache.org/jira/browse/DERBY-4664
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.1.3.1, 10.2.2.0, 10.3.3.0, 10.4.2.0, 10.5.3.0, 10.6.1.0
> Reporter: Kathey Marsden
> Fix For: 10.3.3.1, 10.4.2.1, 10.5.3.1, 10.6.1.1
>
> Attachments: derby-4664_diff.txt
>
>
> Some Derby internal Stored procedures and functions call DriverManager.getConnection("jdbc:default:connection"); and this url can be recognized by another Driver in the same classpath that is used for server side JDBC for another product. For example the below occurred in NetworkServer when JCC was also loaded because the JCC Type 2 driver is used for server side JDBC:
> java.lang.UnsatisfiedLinkError:
> db2jcct2 (Not found in java.library.path): ERRORCODE=-4472, SQLSTATE=null
> com.ibm.db2.jcc.b.SqlException
> at com.ibm.db2.jcc.b.bd.a(bd.java:660)
> at com.ibm.db2.jcc.b.bd.a(bd.java:60)
> at com.ibm.db2.jcc.b.bd.a(bd.java:94)
> at com.ibm.db2.jcc.t2.a.a(a.java:37)
> at com.ibm.db2.jcc.t2.T2Configuration.<clinit>(T2Configuration.java:94)
> at java.lang.J9VMInternals.initializeImpl(Native Method)
> at java.lang.J9VMInternals.initialize(J9VMInternals.java:196)
> at com.ibm.db2.jcc.DB2Driver.connect(DB2Driver.java:211)
> at java.sql.DriverManager.getConnection(DriverManager.java:572)
> at java.sql.DriverManager.getConnection(DriverManager.java:218)
> at org.apache.derby.impl.jdbc.LOBStoredProcedure.getEmbedConnection(Unknown Source)
> at org.apache.derby.impl.jdbc.LOBStoredProcedure.getClobObjectCorrespondingtoLOCATOR(Unknown Source)
> at org.apache.derby.impl.jdbc.LOBStoredProcedure.CLOBGETLENGTH(Unknown Source)
> at org.apache.derby.exe.acf81e0010x0128x864dxbe82x00004c9b380d12.e0(Unknown Source)
> at org.apache.derby.impl.services.reflect.DirectCall.invoke(Unknown Source)
> at org.apache.derby.impl.sql.execute.RowResultSet.getNextRowCore(Unknown Source)
> at org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.getNextRow(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedResultSet.movePosition(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedResultSet.next(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedCallableStatement.executeStatement(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(Unknown Source)
> at org.apache.derby.impl.drda.DRDAStatement.execute(Unknown Source)
> at org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLSTTobjects(Unknown Source)
> at org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLSTT(Unknown Source)
> at org.apache.derby.impl.drda.DRDAConnThread.processCommands(Unknown Source)
> at org.apache.derby.impl.drda.DRDAConnThread.run(Unknown Source)
> I think we can avoid this specific error by changing LobStoredProcedure (and perhaps other internal procedures) to use the code in SystemProcedures.getDefaultConn() which always connects to Derby by using = InternalDriver.activeDriver()
> This of course will not solve the general problem for any user created procedure or function that performs SQL. I am not sure if there is a good solution for that. I asked the JCC Driver team to see if there is a way they can determine if they are running inside the DB2 process or not. but regardless of these product workarounds I think the basic problem is design flaw in the specification. DriverManager cannot differentiate the URL if all database products use the same one for server side JDBC.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-4664) Change Derby internal stored
procedures to avoid DriverManager.getConnection("jdbc:default:connection")
as it may be recognized by other Drivers
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12870233#action_12870233 ]
Kathey Marsden commented on DERBY-4664:
---------------------------------------
I backported this fix to 10.3 to meet urgent need there. I will take care of 10.6, 10.5, and 10.4 next week.
> Change Derby internal stored procedures to avoid DriverManager.getConnection("jdbc:default:connection") as it may be recognized by other Drivers
> ------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4664
> URL: https://issues.apache.org/jira/browse/DERBY-4664
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.1.3.1, 10.2.2.0, 10.3.3.0, 10.4.2.0, 10.5.3.0, 10.6.1.0
> Reporter: Kathey Marsden
> Fix For: 10.3.3.1, 10.4.2.1, 10.5.3.1, 10.6.1.1
>
> Attachments: derby-4664_diff.txt
>
>
> Some Derby internal Stored procedures and functions call DriverManager.getConnection("jdbc:default:connection"); and this url can be recognized by another Driver in the same classpath that is used for server side JDBC for another product. For example the below occurred in NetworkServer when JCC was also loaded because the JCC Type 2 driver is used for server side JDBC:
> java.lang.UnsatisfiedLinkError:
> db2jcct2 (Not found in java.library.path): ERRORCODE=-4472, SQLSTATE=null
> com.ibm.db2.jcc.b.SqlException
> at com.ibm.db2.jcc.b.bd.a(bd.java:660)
> at com.ibm.db2.jcc.b.bd.a(bd.java:60)
> at com.ibm.db2.jcc.b.bd.a(bd.java:94)
> at com.ibm.db2.jcc.t2.a.a(a.java:37)
> at com.ibm.db2.jcc.t2.T2Configuration.<clinit>(T2Configuration.java:94)
> at java.lang.J9VMInternals.initializeImpl(Native Method)
> at java.lang.J9VMInternals.initialize(J9VMInternals.java:196)
> at com.ibm.db2.jcc.DB2Driver.connect(DB2Driver.java:211)
> at java.sql.DriverManager.getConnection(DriverManager.java:572)
> at java.sql.DriverManager.getConnection(DriverManager.java:218)
> at org.apache.derby.impl.jdbc.LOBStoredProcedure.getEmbedConnection(Unknown Source)
> at org.apache.derby.impl.jdbc.LOBStoredProcedure.getClobObjectCorrespondingtoLOCATOR(Unknown Source)
> at org.apache.derby.impl.jdbc.LOBStoredProcedure.CLOBGETLENGTH(Unknown Source)
> at org.apache.derby.exe.acf81e0010x0128x864dxbe82x00004c9b380d12.e0(Unknown Source)
> at org.apache.derby.impl.services.reflect.DirectCall.invoke(Unknown Source)
> at org.apache.derby.impl.sql.execute.RowResultSet.getNextRowCore(Unknown Source)
> at org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.getNextRow(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedResultSet.movePosition(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedResultSet.next(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedCallableStatement.executeStatement(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(Unknown Source)
> at org.apache.derby.impl.drda.DRDAStatement.execute(Unknown Source)
> at org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLSTTobjects(Unknown Source)
> at org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLSTT(Unknown Source)
> at org.apache.derby.impl.drda.DRDAConnThread.processCommands(Unknown Source)
> at org.apache.derby.impl.drda.DRDAConnThread.run(Unknown Source)
> I think we can avoid this specific error by changing LobStoredProcedure (and perhaps other internal procedures) to use the code in SystemProcedures.getDefaultConn() which always connects to Derby by using = InternalDriver.activeDriver()
> This of course will not solve the general problem for any user created procedure or function that performs SQL. I am not sure if there is a good solution for that. I asked the JCC Driver team to see if there is a way they can determine if they are running inside the DB2 process or not. but regardless of these product workarounds I think the basic problem is design flaw in the specification. DriverManager cannot differentiate the URL if all database products use the same one for server side JDBC.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-4664) Change Derby internal stored
procedures to avoid DriverManager.getConnection("jdbc:default:connection")
as it may be recognized by other Drivers
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12869496#action_12869496 ]
Kristian Waagan commented on DERBY-4664:
----------------------------------------
The patch looks okay to me.
Note that the import of both Connection and DriverManager can be removed (they are unused).
Other nits:
- one long line
- blank line at the end of the method
Interesting issue...
> Change Derby internal stored procedures to avoid DriverManager.getConnection("jdbc:default:connection") as it may be recognized by other Drivers
> ------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4664
> URL: https://issues.apache.org/jira/browse/DERBY-4664
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.1.3.1, 10.2.2.0, 10.3.3.0, 10.4.2.0, 10.5.3.0, 10.6.1.0
> Reporter: Kathey Marsden
> Fix For: 10.3.3.1, 10.4.2.1, 10.5.3.1, 10.6.1.1
>
> Attachments: derby-4664_diff.txt
>
>
> Some Derby internal Stored procedures and functions call DriverManager.getConnection("jdbc:default:connection"); and this url can be recognized by another Driver in the same classpath that is used for server side JDBC for another product. For example the below occurred in NetworkServer when JCC was also loaded because the JCC Type 2 driver is used for server side JDBC:
> java.lang.UnsatisfiedLinkError:
> db2jcct2 (Not found in java.library.path): ERRORCODE=-4472, SQLSTATE=null
> com.ibm.db2.jcc.b.SqlException
> at com.ibm.db2.jcc.b.bd.a(bd.java:660)
> at com.ibm.db2.jcc.b.bd.a(bd.java:60)
> at com.ibm.db2.jcc.b.bd.a(bd.java:94)
> at com.ibm.db2.jcc.t2.a.a(a.java:37)
> at com.ibm.db2.jcc.t2.T2Configuration.<clinit>(T2Configuration.java:94)
> at java.lang.J9VMInternals.initializeImpl(Native Method)
> at java.lang.J9VMInternals.initialize(J9VMInternals.java:196)
> at com.ibm.db2.jcc.DB2Driver.connect(DB2Driver.java:211)
> at java.sql.DriverManager.getConnection(DriverManager.java:572)
> at java.sql.DriverManager.getConnection(DriverManager.java:218)
> at org.apache.derby.impl.jdbc.LOBStoredProcedure.getEmbedConnection(Unknown Source)
> at org.apache.derby.impl.jdbc.LOBStoredProcedure.getClobObjectCorrespondingtoLOCATOR(Unknown Source)
> at org.apache.derby.impl.jdbc.LOBStoredProcedure.CLOBGETLENGTH(Unknown Source)
> at org.apache.derby.exe.acf81e0010x0128x864dxbe82x00004c9b380d12.e0(Unknown Source)
> at org.apache.derby.impl.services.reflect.DirectCall.invoke(Unknown Source)
> at org.apache.derby.impl.sql.execute.RowResultSet.getNextRowCore(Unknown Source)
> at org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.getNextRow(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedResultSet.movePosition(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedResultSet.next(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedCallableStatement.executeStatement(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(Unknown Source)
> at org.apache.derby.impl.drda.DRDAStatement.execute(Unknown Source)
> at org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLSTTobjects(Unknown Source)
> at org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLSTT(Unknown Source)
> at org.apache.derby.impl.drda.DRDAConnThread.processCommands(Unknown Source)
> at org.apache.derby.impl.drda.DRDAConnThread.run(Unknown Source)
> I think we can avoid this specific error by changing LobStoredProcedure (and perhaps other internal procedures) to use the code in SystemProcedures.getDefaultConn() which always connects to Derby by using = InternalDriver.activeDriver()
> This of course will not solve the general problem for any user created procedure or function that performs SQL. I am not sure if there is a good solution for that. I asked the JCC Driver team to see if there is a way they can determine if they are running inside the DB2 process or not. but regardless of these product workarounds I think the basic problem is design flaw in the specification. DriverManager cannot differentiate the URL if all database products use the same one for server side JDBC.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.