[ 
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.

Reply via email to