Once initialized , a static ref to a type retains its instantiated object in
memory until the containing app domain is recycled (either as part of worker
process recycle , or otherwise ) ...
For an asp.net app , I want to use the singleton strictly within the
processing of a single page request ...
( Complex conditional logic in the page processing means that the "Instance"
method or property on the singleton won't necessarily be called , and so the
private member won't necessarily be instantiated. )
If I provide a function that can be called to set the static ref to null (
to dispose of the referred to object before page unload ) , what
complications are there to proper design of a scalable singleton ?
Or is a singleton not the best solution for my design goal .... ?
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
<"John A Grandy" <johnagrandy-at-yahoo-dot-com>> wrote:
Hmmm ... well, it looks like I've obtained a misunderstanding of how Java
handles static vars from a design patterns book I won't name.
This book states that the traditional Singleton will have its static vars'
assignment constructors invoked on load of the class ... which I
understand
to mean load of the class' assembly.
There's no such concept of "assembly" in Java, so that can't be right.
However, the semantics of when a type's initialization occurs is in the
Java language specification. From section 12.4.1:
<quote>
A class or interface type T will be initialized immediately before the
first occurrence of any one of the following:
* T is a class and an instance of T is created.
* T is a class and a static method declared by T is invoked.
* A static field declared by T is assigned.
* A static field declared by T is used and the reference to the
field is not a compile-time constant (§15.28). References to compile-
time constants must be resolved at compile time to a copy of the
compile-time constant value, so uses of such a field never cause
initialization.
</quote>
In other words, it's pretty similar to the C# behaviour when there's a
static constructor present. (When there's no static constructor present
in C#, the CLR has more discretion in terms of exactly when type
initialization occurs.)
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog:
http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too