db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: Dropped procedure still cached?
Date Mon, 12 May 2008 13:14:17 GMT
Hi Tian,

It sounds as though the old procedure class is stuck in Derby's 
classloaders. This topic comes up occasionally and the user guides 
should probably explain this better.

1) If your user-written procedures and functions live inside jar files 
which you have loaded into your  Derby database, then you need to 
replace those jar files by invoking the sqlj.replace_jar system 
procedure. For more information, please see the section titled "Storing 
jar files in a database" in the Derby Tools and Utilities Guide: 
http://db.apache.org/derby/docs/10.4/tools/

2) If, however, your user-written procedures and functions live outside 
your Derby database and are simply wired into the VM's classpath, then 
you need to bring Derby down and back up in order to reload the 
user-written classes which you have changed. Once Derby loads a class 
from the VM's classpath, that class definition remains in the 
classloader until you restart Derby.

Hope this helps,
-Rick

Tian TAN wrote:
> My class just look like the one below. I did re-run it to make sure
> the class file is changed and clean. Am I missing something here?
>
> package derbylab;
>
> public class TestProcedure {
>   public static void main(String[] args){
> 	  print();
>   }	
> 	
>   public static void print(){
> 	  System.out.println("AAA");
>   }
> }
>
>
> 2008/5/11 sin(EaTing), <ussraf@gmail.com>:
>   
>> You need to reimport your jar containing the procedure definition?
>>
>> On Sun, May 11, 2008 at 9:28 PM, Tian TAN <tian.tan0831@googlemail.com>
>> wrote:
>>     
>>> Hi all,
>>>
>>> I am new to derby and I recently encountering the following problem,
>>> can someone help (by explaining a bit or pointing me to some doc)?
>>>
>>> Environment
>>> I am running derby server using eclipse plugin, and issuing the SQL
>>> through ij.
>>>
>>> Step 1
>>>
>>> connect 'jdbc:derby://localhost:1527/testDB;create=true;';
>>>
>>> CREATE PROCEDURE testPrint (  )
>>>  MODIFIES SQL DATA
>>>  PARAMETER STYLE JAVA
>>>  LANGUAGE JAVA
>>>  EXTERNAL NAME 'derbylab.TestProcedure.print' -- print 'AAA' in the Java
>>> class
>>> ;
>>>
>>> CALL testPrint();
>>>
>>> Statement executed correctly and prints out 'AAA.
>>>
>>> Step 2
>>> Then I changed the print 'AAA' in the Java class to print 'BBB' and
>>> execute
>>>
>>> connect 'jdbc:derby://localhost:1527/testDB;create=true;';
>>>
>>> DROP PROCEDURE testPrint;
>>> CALL testPrint(); -- make sure it's dropped. No surprise ERROR 42Y03
>>> Procedure not found.
>>>
>>> CREATE PROCEDURE testPrint (  )
>>>  MODIFIES SQL DATA
>>>  PARAMETER STYLE JAVA
>>>  LANGUAGE JAVA
>>>  EXTERNAL NAME 'derbylab.TestProcedure.print'
>>>  --- now I expect it to print 'BBB', since I've changed the Java class
>>> ;
>>> CALL testPrint();
>>> Statement executed but still prints out 'AAA' instead of 'BBB'.
>>>
>>> This is a bit surprise to me. I noticed that in between step 1 and
>>> step2 if I restart derby network server the result is correct. So it
>>> seems to me that the testPrint PROCEDURE is cached and not dropped?
>>> (i.e. if the exact same testPrint PROCEDURE is recreated the old
>>> cached version will be called).
>>>
>>> Could someone help? (or pointing me to some online doc or some source
>>> code I should look? ) Thanks.
>>>
>>> Tim
>>>       
>>     


Mime
View raw message