SQLJ.REFRESH_CL ASSES() ....

[Raquel]

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\functio n directory (not built into JAR files).

While the manuals state that SQLJ.REFRESH_CL ASSES() 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_CL ASSES() was NOT refreshing my SQLJ stored procedures in
\sqllib\functio n. 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_CL ASSES() 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_CL ASSES() should not have worked even with JDBC.

What are your experiences in this regard.

TIA
Raquel.

[Sean McKeough]

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\functio n library (and are not defined as JAR files).

SQLJ.REFRESH_CL ASSES() 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\functio n, 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.