Hi David,

Sorry, I don't know the details of stored procs in Java. I'd have to look at the stored proc code to see what assumptions it makes about where the Java class is. There are many possibilities that make sense: use Derby's class loader; use the context class loader of the caller; create a new class in Derby's class loader from the byte stream that represents the stored proc class.

My comment below had to do with user-domain classes that are stored in Derby as objects...


On Nov 9, 2005, at 2:33 PM, David W. Van Couvering wrote:

Thanks, Craig.  One comment below...

Craig L Russell wrote:

Hi Kathey,
The approach looks good. More comments below.
On Nov 9, 2005, at 9:14 AM, David W. Van Couvering wrote:

Hi, Kathey.  At first glance it looks good to me.  I'm assuming *all* classes your app needs are available to the from the URL you specify, because you are not specifying a parent classloader when you create it.  

As I understand it, the only classes that need to be available via the special classloader are the Derby implementation classes and its dependencies. JDBC is a pretty good abstraction layer that uses pass-by-value semantics not pass-by-reference semantics, so as long as you're not using user classes inside your database you should be ok.

Hm, user classes may be used in stored procedures, right?


Craig Russell

Architect, Sun Java Enterprise System http://java.sun.com/products/jdo

408 276-5638 mailto:Craig.Russell@sun.com

P.S. A good JDO? O, Gasp!