db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oyvind.Bakk...@Sun.COM
Subject Re: Question about using URLClassLoader and Derby
Date Mon, 14 Nov 2005 14:48:06 GMT
Kathey Marsden wrote:
> I am moving this to derby-dev as  I think my new questions are more
> appropriate for this list.
> Oyvind's suggestion to make a DerbyURLClassLoader to filter out the
> derby classes from the parent class loader all seems to be working ok
> (with some very minimal testing). 
> David W. Van Couvering wrote (for Binod):
>>Make sure that there is only one URL classloader instance that has
>>access to the derby jar files. And make sure that whenever a code
>>accesses the datasource, it always go thru newDataSource method, then
>>yes, it should work.
> I just want to verify that this just means that my app should use the
> same loader if it needed to get another datasource for say shutting down
> the database.  Other applications should be able to use their own
> DerbyURLClassLoaders to access Derby as long as they are accessing
> different databases, right?

I think "as long as they are accessing different Derby 
systems/instances" is more precise to say than different "databases".

>>p.s: This is all assuming that derby code doent do any other interesting
>>classloader mechanism inside :-). For example, it can use Thread's
>>context classLoader to load some other part of derby that might break.
> Is there anything like Binod describes  in Derby that might cause
> problems (e.g. code for loading generated byte code, loading databases
> from jars or aggregates) ?   

Classloaders which use the default parent classloader should not pose a 
problem. It's that Thread's context classloader which is spooky. I found 
references to getContextClassLoader in three files:


I haven't looked at what's being done with that classloader in those 
files, so I can't really say whether this is an issue.

> One other issue I have encountered is  that I am not sure how to handle
> the derby error log (derby.log).    The configuration for this is only
> provided with System properties or entries in the derby.properties file
> which would affect other apps.  How do I create my own isolated error
> log with out clobbering the error logs of other apps or having them
> clobber mine?

Hm... create your own java.lang.System and load it with the 
DerbyURLClassLoader? ;o) I'm joking, of course. Are the system 
properties read only once, during initialization of a Derby instance? If 
so, you could modify the System properties before loading the next Derby 
instance. Of course, that requires synchronization and doesn't work in 
an app server with applications that don't know about each other. I 
don't have a good workaround for you here. The best thing would be to 
have some other way to set these properties than through the System 
properties, but if that's not available today...

Oyvind Bakksjo
Sun Microsystems, Database Technology Group
Trondheim, Norway

View raw message