SEO

Following problem, hope someone can help us:
We have a testserver with three test-databases for each of our current
services (production servers are one machine per service). Having
three databse on one server worked without a problem (except from some
performance-issues...) till we created stored procedures with same
name (and different parameters) in two of the databases.

We use one .jar with the procedure's name to encapsulate all files
necessary for one procedure. But because DB2 only arranges the files
per user (in sqllib/function/jar/(username)) and NOT per database,
installing one procedure would overwrite the other. So I changed our
batch to install procedures so it would append the database's name to
the .jar, believing that this would solve the problem. Obviuosly it
did not. Although there are now individual .jar's for each database,
db2 seems to always load the class from the .jar first installed. So
if there are two .jars containing the same classes, there will only
one be used, no matter what .jar you specified. This undermines imo
the whole idea of having .jar files, because the java interpreter
should load exactly and only the classes of the .jar defined in CREATE
PROCEDURE.

Now does anybody know if this is a known issue or if there is somthing
wrong with our configuration. Has anyone a easy solution to this? Or
do we have to give a unique name to all our classes used for sps from
now on?

Thanks for your support

Janick

This is a documented limitation...db2 will always pick up the first
matching class from the classpath.

Janick wrote:

> Following problem, hope someone can help us:
> We have a testserver with three test-databases for each of our current
> services (production servers are one machine per service). Having
> three databse on one server worked without a problem (except from some
> performance-issues...) till we created stored procedures with same
> name (and different parameters) in two of the databases.
>
> We use one .jar with the procedure's name to encapsulate all files
> necessary for one procedure. But because DB2 only arranges the files
> per user (in sqllib/function/jar/(username)) and NOT per database,
> installing one procedure would overwrite the other. So I changed our
> batch to install procedures so it would append the database's name to
> the .jar, believing that this would solve the problem. Obviuosly it
> did not. Although there are now individual .jar's for each database,
> db2 seems to always load the class from the .jar first installed. So
> if there are two .jars containing the same classes, there will only
> one be used, no matter what .jar you specified. This undermines imo
> the whole idea of having .jar files, because the java interpreter
> should load exactly and only the classes of the .jar defined in CREATE
> PROCEDURE.
>
> Now does anybody know if this is a known issue or if there is somthing
> wrong with our configuration. Has anyone a easy solution to this? Or
> do we have to give a unique name to all our classes used for sps from
> now on?
>
> Thanks for your support
>
> Janick

Do you know if this is fixed with version 8.1?

It is not. There are plans to revise the JVM in v9 to lift this restriction.

Janick wrote:
> Do you know if this is fixed with version 8.1?

jabernet@gmx.ch (Janick) wrote in message news:<e719b57c.0311060315.1f3bba8b@posting.google. com>...
> Do you know if this is fixed with version 8.1?

I have been told this is going to be fixed in DB2 V9 that is comming
up somewhere in May 2004. The workarounds now would be to have all
your java classes named uniquely across the DB2 instance (that can be
automated by your app build/deploy process) or having a separate
instance for each applicatoin/developer (less feasible).

Eugene

eugene@profitlogic.com (Eugene) wrote in message news:<9573e6b2.0311060623.4e99b900@posting.google. com>...
> jabernet@gmx.ch (Janick) wrote in message news:<e719b57c.0311060315.1f3bba8b@posting.google. com>...
> > Do you know if this is fixed with version 8.1?
>
> I have been told this is going to be fixed in DB2 V9 that is comming
> up somewhere in May 2004.
May 2004? Didn't 8.1 just come out recently?

> The workarounds now would be to have all
> your java classes named uniquely across the DB2 instance (that can be
> automated by your app build/deploy process)
I did exactly that. Had to change our batch. Now all procedures lie in
a unique package per db/project.

Hope IBM will fix this (they should already have done so) because it
is a really stupid behaviour to look in all jars for corresponding
class (especially when you explicitily provided a jar-name in
create-procedure).

Thanks for your help guys.