From: Tim.Clarke at manifest.co.uk (Tim Clarke)
Date: Mon, 27 Feb 2006 19:30:45 -0000
Subject: [Pljava-dev] PL/Java functions and JDBC
Message-ID: <44D9FC40FD695B4E85F1C59965C27E0FAA4D8B@man3>

> -----Original Message-----
> From: Thomas Hallgren [mailto:thomas at tada.se] 
> Sent: 25 February 2006 13:54
> To: Tim Clarke
> Subject: Re: [Pljava-dev] PL/Java functions and JDBC
> 
> My tests were not very scientific :-). I just measured the overall 
> consumption as I spawned more and more connections. I guess 
> any system 
> monitor tool would do. You can use 'top' for instance.

Hehe - and I thought there was some kind of "the size of my VM object
total is ..." call.

> The recommended way to do it is to drop your connection and 
> create a new 
> one. Without that there can never be a guarantee that the new 
> code will 
> be used. Compare to a normal Java process where you change the 
> classloaders in runtime. There might be several places where static 
> variables, objects on the call stack, etc. holds on to old 
> classes and 
> instances of those classes.

Yeah, that's what I'm doing, just dropping the conn.

> Having said that, PL/Java could make a better effort then what's done 
> today. At present, it will drop the classloaders of all 
> schemas but it 
> will not free up the function to method map. That would 
> definitely be an 
> improvement. It's not trivial to implement though.

OK

> The current CVS now contains code that resets the function to 
> method map 
> when jars are installed, replaced, or removed, and when the 
> classpath is 
> changed. It will be included in the 1.3 release of PL/Java. I don't 
> think that's far away, couple of weeks tops.

That's call - thanks and kudos to the team for their work and that.

> 
> Regards,
> Thomas Hallgren