By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,851 Members | 1,131 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,851 IT Pros & Developers. It's quick & easy.

SQLJ.REFRESH_CLASSES() ....

P: n/a
UDB PE 8.1 on Win XP.

ok, this function caused a lot of grief today. My stored procedures
are java stored procedures, all FENCED and directly placed in
\sqllib\function directory (not built into JAR files).

While the manuals state that SQLJ.REFRESH_CLASSES() only refreshes the
routines built into JAR files, I have been successfully refreshing my
JDBC stored procedures with this function.

A couple of days back, I started developing SQLJ stored procedures and
it took me a long while to figure out that all the strange errors I
was receiving while attempting to run the SQLJ stored procedures
(messages like arguments not being compatible etc.) were because
SQLJ.REFRESH_CLASSES() was NOT refreshing my SQLJ stored procedures in
\sqllib\function. I had to stop and start the database manager
everytime I changed and recompiled a stored procedure. This solved the
problem.

KEEPFENCED in dbm config. file is set to YES (default).

Anyway, so my question is: Is someone on the list aware of what the
deal with SQLJ.REFRESH_CLASSES() is? Why does it work with JDBC
procedures and not with SQLJ procedures. Actually, per the manual, it
should work *only* for stored procedures that are built into JAR
files. Since my JDBC stored procedures are not built into JAR files,
SQLJ.REFRESH_CLASSES() should not have worked even with JDBC.

What are your experiences in this regard.

TIA
Raquel.
Nov 12 '05 #1
Share this Question
Share on Google+
10 Replies


P: n/a
Raquel wrote:
UDB PE 8.1 on Win XP.

ok, this function caused a lot of grief today. My stored procedures
are java stored procedures, all FENCED and directly placed in
\sqllib\function directory (not built into JAR files).

While the manuals state that SQLJ.REFRESH_CLASSES() only refreshes the
routines built into JAR files, I have been successfully refreshing my
JDBC stored procedures with this function.


I don't know the DB2 internals well enough to say why it did work for some
of your cases, but:

If the manual does *not* state that it works for non-jar files, than you
can't rely on your tests. You were just lucky that it did work with JDBC
classes in the first place.

--
Knut Stolze
Information Integration
IBM Germany / University of Jena
Nov 12 '05 #2

P: n/a
It should work for both...we destroy the classloader when this function
is called. Can you contact support?

Raquel wrote:
UDB PE 8.1 on Win XP.

ok, this function caused a lot of grief today. My stored procedures
are java stored procedures, all FENCED and directly placed in
\sqllib\function directory (not built into JAR files).

While the manuals state that SQLJ.REFRESH_CLASSES() only refreshes the
routines built into JAR files, I have been successfully refreshing my
JDBC stored procedures with this function.

A couple of days back, I started developing SQLJ stored procedures and
it took me a long while to figure out that all the strange errors I
was receiving while attempting to run the SQLJ stored procedures
(messages like arguments not being compatible etc.) were because
SQLJ.REFRESH_CLASSES() was NOT refreshing my SQLJ stored procedures in
\sqllib\function. I had to stop and start the database manager
everytime I changed and recompiled a stored procedure. This solved the
problem.

KEEPFENCED in dbm config. file is set to YES (default).

Anyway, so my question is: Is someone on the list aware of what the
deal with SQLJ.REFRESH_CLASSES() is? Why does it work with JDBC
procedures and not with SQLJ procedures. Actually, per the manual, it
should work *only* for stored procedures that are built into JAR
files. Since my JDBC stored procedures are not built into JAR files,
SQLJ.REFRESH_CLASSES() should not have worked even with JDBC.

What are your experiences in this regard.

TIA
Raquel.

Nov 12 '05 #3

P: n/a
I did not follow your earlier posts so forgive me if this has already been
said.

In my experience, which is with DB2 V7.2 and earlier versions, the key
factor in getting fenced stored procedures to refresh themselves correctly
is to set KEEPDARI to NO. You can do this via:
db2 upd dbm cfg using keepdari no

KEEPDARI is a performance setting that should normally be set to YES for a
production environment but should almost certainly be set to NO for a
development environment. Otherwise, you get the sorts of problems you are
having.

As I said, I haven't used DB2 V8 yet so this advice may not be applicable
any longer but it certainly made a big difference in V7.2.

There are other things that can cause stored procedures to have refresh
issues but KEEPDARI is the biggest one in my experience. However, if you
have KEEPDARI set appropriately, there are two other things you should
explore:
1) If you are hand-coding your procedures - as opposed to using the Stored
Procedure Builder/Development Center - your program preparation procedures
may not be correct. You may be compiling the latest version of your program
but your preparation procedures may be putting an older version of the
..class file in your SQLLIB\FUNCTION\JAR\<schema> directory.
2) You may have *both* a .class file and a .jar containing the same program
in your SQLLIB\
FUNCTION\JAR\<schema>\ directory. In this case, DB2 will always use the
..class file in preference to your .jar, even if the .class file is an older
version.

I've managed to make all three of these mistakes at one point or another so
I understand your frustration with the procedures not refreshing properly.
However, if you make sure that KEEPDARI is NO in a development environment
and verify that your preparation procedures are storing the current version
of the .class file in the SQLLIB\FUNCTION\JAR\<schema> directory, your
problem with refreshing classes *should* go away.

Rhino

"Raquel" <ra****************@yahoo.com> wrote in message
news:9a**************************@posting.google.c om...
UDB PE 8.1 on Win XP.

ok, this function caused a lot of grief today. My stored procedures
are java stored procedures, all FENCED and directly placed in
\sqllib\function directory (not built into JAR files).

While the manuals state that SQLJ.REFRESH_CLASSES() only refreshes the
routines built into JAR files, I have been successfully refreshing my
JDBC stored procedures with this function.

A couple of days back, I started developing SQLJ stored procedures and
it took me a long while to figure out that all the strange errors I
was receiving while attempting to run the SQLJ stored procedures
(messages like arguments not being compatible etc.) were because
SQLJ.REFRESH_CLASSES() was NOT refreshing my SQLJ stored procedures in
\sqllib\function. I had to stop and start the database manager
everytime I changed and recompiled a stored procedure. This solved the
problem.

KEEPFENCED in dbm config. file is set to YES (default).

Anyway, so my question is: Is someone on the list aware of what the
deal with SQLJ.REFRESH_CLASSES() is? Why does it work with JDBC
procedures and not with SQLJ procedures. Actually, per the manual, it
should work *only* for stored procedures that are built into JAR
files. Since my JDBC stored procedures are not built into JAR files,
SQLJ.REFRESH_CLASSES() should not have worked even with JDBC.

What are your experiences in this regard.

TIA
Raquel.

Nov 12 '05 #4

P: n/a
Raquel wrote:
UDB PE 8.1 on Win XP.

ok, this function caused a lot of grief today. My stored procedures
are java stored procedures, all FENCED and directly placed in
\sqllib\function directory (not built into JAR files).

While the manuals state that SQLJ.REFRESH_CLASSES() only refreshes the
routines built into JAR files, I have been successfully refreshing my
JDBC stored procedures with this function.

A couple of days back, I started developing SQLJ stored procedures and
it took me a long while to figure out that all the strange errors I
was receiving while attempting to run the SQLJ stored procedures
(messages like arguments not being compatible etc.) were because
SQLJ.REFRESH_CLASSES() was NOT refreshing my SQLJ stored procedures in
\sqllib\function. I had to stop and start the database manager
everytime I changed and recompiled a stored procedure. This solved the
problem.

KEEPFENCED in dbm config. file is set to YES (default).

Anyway, so my question is: Is someone on the list aware of what the
deal with SQLJ.REFRESH_CLASSES() is? Why does it work with JDBC
procedures and not with SQLJ procedures. Actually, per the manual, it
should work *only* for stored procedures that are built into JAR
files. Since my JDBC stored procedures are not built into JAR files,
SQLJ.REFRESH_CLASSES() should not have worked even with JDBC.

What are your experiences in this regard.

TIA
Raquel.


It should work with all fenced java stored procedures. Set KEEPFENCED to
NO would probably get around the problem. However, I am surprised that
sqlj would make a difference here. Which fixpack are you on? What kind
of changes are you making? SQLJ creates static packages, so maybe it's
not the stored procedure that is not getting updated, rather you were
using a cached package.

Nov 12 '05 #5

P: n/a
>
If the manual does *not* state that it works for non-jar files, than you
can't rely on your tests. You were just lucky that it did work with JDBC
classes in the first place.


Well, the manual does not say that you can *not* use
SQLJ.REFRESH_CLASSES for non-jar files. Here is the exact section from
the manual:

"
For updating Java™ routines that are built into JAR files, you must
issue a
CALL SQLJ.REFRESH_CLASSES() statement to force DB2® to load the new
classes. If you do not issue the CALL SQLJ.REFRESH_CLASSES() statement
after you update Java routine classes, DB2 continues to use the
previous
versions of the classes. DB2 refreshes the classes when a COMMIT or
ROLLBACK occurs. The CALL SQLJ.REFRESH_CLASSES() statement only
applies to FENCED routines. To update NOT FENCED routines, you must
either restart the database manager and replace the class, or use the
steps
described above to create a new class and use the ALTER statement to
reference it.
"

Thanks.
Raquel.
Nov 12 '05 #6

P: n/a
Sean McKeough <mc******@nospam.ca.ibm.com> wrote in message news:<cb**********@hanover.torolab.ibm.com>...
It should work for both...we destroy the classloader when this function
is called. Can you contact support?


Sean, pardon my ignorance in this regard, but what do you mean by
"..we destroy the classloader when this function is called..". What is
classloader and how do you destroy it and how does it help to refresh
classes...probably herein lies the clue to my problem. I am using
8.1.3.

TIA
Raquel.
Nov 12 '05 #7

P: n/a
Raquel wrote:

If the manual does *not* state that it works for non-jar files, than you
can't rely on your tests. You were just lucky that it did work with JDBC
classes in the first place.
Well, the manual does not say that you can *not* use


So it does mean that REFRESH_CLASSES is supported for JAR files. That's
all. If you use it for anything else, you can't complain if it doesn't
work.
SQLJ.REFRESH_CLASSES for non-jar files. Here is the exact section from
the manual:

"
For updating Java™ routines that are built into JAR files, you must
issue a
CALL SQLJ.REFRESH_CLASSES() statement to force DB2® to load the new
classes. If you do not issue the CALL SQLJ.REFRESH_CLASSES() statement
after you update Java routine classes, DB2 continues to use the
previous
versions of the classes. DB2 refreshes the classes when a COMMIT or
ROLLBACK occurs. The CALL SQLJ.REFRESH_CLASSES() statement only
applies to FENCED routines. To update NOT FENCED routines, you must
either restart the database manager and replace the class, or use the
steps
described above to create a new class and use the ALTER statement to
reference it.
"


Yeah, because it doesn't say anything about non-JAR files, it would mean
that non-JAR files are not supported. End of story.

Granted, Sean said that it should work for all Java classes. So I would
trust him in that case.

--
Knut Stolze
Information Integration
IBM Germany / University of Jena
Nov 12 '05 #8

P: n/a
I now have thoroughly conducted various tests and following are the
results. They are consistent whether the stored procedures are JDBC or
SQLJ (so, at least that's good). I am at 8.1.3 UDB PE on XP. As
already mentioned, all my procedures are defined as FENCED and are in
\sqllib\function library (and are not defined as JAR files).

SQLJ.REFRESH_CLASSES() does not have ANY effect at all; in other words
executing it does NOT refresh the stored procedure code (in my
case...that is in case of stored procedures directly defined in
\sqllib\function, probably it does in case stored procedures are
defined in JAR format).

The parameter that does make a difference is: KEEPFENCED.

1. If KEEPFENCED=YES, it is imperitive to issue a db2stop/db2start to
refresh the stored procedure bytecode(once you change the stored
procedure and compile it).
2. If KEEPFENCED=NO, the stored procedures bytecode is automatically
refreshed (the moment you compile your changed procedure).

Thanks.
Raquel.
Nov 12 '05 #9

P: n/a
The classloader is an object used by java to manage classes. When you're
running a JVM, it has a default classloader...this loader will cache
classes etc. We have our own version of a classloader, that we can
adjust the behavior of...in particular, we can recycle it, so that it
_should_ pick up new versions of classes in the path.

I'm wondering if in your case SQLJ is caching something we can't control
....not sure though (might be worth trying to put your sqlj classes in a
jar)...

Raquel wrote:
Sean McKeough <mc******@nospam.ca.ibm.com> wrote in message news:<cb**********@hanover.torolab.ibm.com>...
It should work for both...we destroy the classloader when this function
is called. Can you contact support?

Sean, pardon my ignorance in this regard, but what do you mean by
"..we destroy the classloader when this function is called..". What is
classloader and how do you destroy it and how does it help to refresh
classes...probably herein lies the clue to my problem. I am using
8.1.3.

TIA
Raquel.

Nov 12 '05 #10

P: n/a
You're either missing a fixpack, or else something is wrong with the
code...you don't want to go to keepfenced=no...you're paying the cost of
starting a jvm on every sp invocation.

Raquel wrote:
I now have thoroughly conducted various tests and following are the
results. They are consistent whether the stored procedures are JDBC or
SQLJ (so, at least that's good). I am at 8.1.3 UDB PE on XP. As
already mentioned, all my procedures are defined as FENCED and are in
\sqllib\function library (and are not defined as JAR files).

SQLJ.REFRESH_CLASSES() does not have ANY effect at all; in other words
executing it does NOT refresh the stored procedure code (in my
case...that is in case of stored procedures directly defined in
\sqllib\function, probably it does in case stored procedures are
defined in JAR format).

The parameter that does make a difference is: KEEPFENCED.

1. If KEEPFENCED=YES, it is imperitive to issue a db2stop/db2start to
refresh the stored procedure bytecode(once you change the stored
procedure and compile it).
2. If KEEPFENCED=NO, the stored procedures bytecode is automatically
refreshed (the moment you compile your changed procedure).

Thanks.
Raquel.

Nov 12 '05 #11

This discussion thread is closed

Replies have been disabled for this discussion.