Prev: setJPEGEncodeParam method not found in JPEGImageEncoder jdk 1.5 and jdk 1.6
Next: HYDROCODONE SIDE EFFECTS INFORMATION
From: Darth Kronos on 26 Nov 2009 09:33
On Nov 26, 2:25 am, Kevin McMurtrie <mcmurt...(a)pixelmemory.us> wrote:
> Sure, that's an example of a very rare and obscure bug.  Unfortunately
> they're the worst kind.

test
From: Tom Anderson on 26 Nov 2009 15:29
On Thu, 26 Nov 2009, Darth Kronos wrote:

> On Nov 26, 2:25�am, Kevin McMurtrie <mcmurt...(a)pixelmemory.us> wrote:
>> Sure, that's an example of a very rare and obscure bug. �Unfortunately
>> they're the worst kind.
>
> test

Good advice.

tom

--
IME the only lousy shags are when she says no! -- John Rowland
From: Tom Anderson on 26 Nov 2009 16:21
On Wed, 25 Nov 2009, Kevin McMurtrie wrote:

> In article <4b0df904$0$274$14726298(a)news.sunsite.dk>,
> Arne Vajh?j <arne(a)vajhoej.dk> wrote:
>
>> Kevin McMurtrie wrote:
>>> Self-registering classes are not the best design. Under extremely rare
>>> circumstances, references from live classes to the registration
>>> container might not exist during a GC - then it's suddenly empty.
>>
>> Any detail son that?
>
> I witnessed it years ago in an early Java web server. There was about a
> 1 in 30 chance that the JDBC driver would initialize yet DriverManager
> didn't have it. It turned out that because Reflection was used to run
> startup components, there was a period of time with no reference to JDBC
> classes or DriverManager. Intentionally holding some references until
> after startup completed was the cure.
>
> Sure, that's an example of a very rare and obscure bug. Unfortunately
> they're the worst kind.

ISTR they changed the rules about this at some point, 1.2 i think -
essentially, a class is referenced by and references its classloader, so a
class that's been loaded won't be unloaded until not only does it have no
instances or direct references, but all classes loaded by its classloader
are also in the same condition (and there are no references to the
classloader).

Now, of course, web servers and app servers tend to do clever tricks with
classloaders, in which case that can indeed happen. But DriverManager is a
standard library class, so it will be loaded by the bootstrap classloader,
which remains aloof from these shenanigans, and will never be
unreferenced. If a static variable in DriverManager refers to the driver
class, then it will never be unloaded.

(Right?)

tom

--
IME the only lousy shags are when she says no! -- John Rowland
First  |  Prev  | 
Pages: 1 2 3 4 5 6 7
Prev: setJPEGEncodeParam method not found in JPEGImageEncoder jdk 1.5 and jdk 1.6
Next: HYDROCODONE SIDE EFFECTS INFORMATION