Re: about singletons (ot)

[Erik Price]

Hey Mike,

Thanks for explaining this.  Your examples make it very clear.  When I 
am done with "Effective Java" I plan to pick up one of the threads books 
(both seem to be equally well-recommended).  I understand the basic 
"idea" of threads, but it's tips like this (using synchronized blocks 
instead of synchronizing the entire method, for performance) that I 
don't know much about.


Erik




Mike Jackson wrote:
Hmm, I wish I'd been paying attention to the list, but basically yes.  You
get finer control by using synchronized code blocks.  Really the major
reason is that you in most cases don't really need to synchronize the entire
method, only small portions of the code.  For example:

	protected static Object lock = new Object();
	protected static int nextId = 1;

	public int getNextId() {
		int id = -1;
		synchronized( lock ) {
			id = nextId;
			nextId++;
		}
		return id;
	}

	public void setNextId( int i ) {
		synchronized( lock ) {
			nextId = i;
		}
	}

As you can see we've got protection for the variable we care about, namely
"nextId".  And we've got it setup such that you can have threads accessing
nextId both in the
getNext and setNext methods.  Now you're probably saying that you could use
the synchronized statement on the methods here.  The answer to that is nope,
when you synchronize the method you're synchronizing on "this", since the
goal is to protect a static variable you're not going to want to do that.

Now even if the nextId wasn't static, you have to consider that you might be
doing other work in the methods.  Work that doesn't need to be synchronized.
For example we might have something like this:

	protected int id = 1;

	public synchronized void spin( int i )
		/* start crit section */
		int i, max = id;
		id++;
		/* end crit section */
		for ( int i = 0; i < max; i++ ) {
			;
		}
	}

Ok, so this code is safe, but is it efficent?  We're blocking threads from
entering which will protect the "id" variable, but we'll be taking time
outside the crit section which will also be protected.  Clearly we don't
really want to do this.  A better way to do this is:

	protected Object lock = new Object();
	protected int id = 1;

	public synchronized void spin( int i )
		int i, max;
		/* start crit section */
		synchronized( lock ) {
			max = id;
			id++;
		}
		/* end crit section */
		for ( int i = 0; i < max; i++ ) {
			;
		}
	}

We're still protecting the crit section, but we aren't impeding other
threads from entering and even completing their pass through the method
prior to our finish.

However sucky examples and all making code thread safe is a lot of work.
There's some "recipes" out there for generating thread safe code, but quite
frankly I don't remember them any more.  But there's some really good books
that we mentioned by other people, the addison westley book is good, and the
o'reilly threads book is good.

--mikej
-=-
mike jackson
[EMAIL PROTECTED]



-----Original Message-
From: Erik Price [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 29, 2003 12:26 PM
To: Tomcat Users List
Subject: Re: about singletons (ot)


So you mean that the original author (mike jackson) was saying that he
used synchronized code blocks to apply a finer level of detail in
specifying what is synchronized and what isn't, as opposed to just
declaring an entire method synchronized?

I understand that synchronization implies a performance penalty, but I
wasn't sure what the advantage to using synchronized blocks over
synchronized methods was.


Erik




Tobias Dittrich wrote:


The reason why you don't want to use synchronized methods is that a
synchronized block can only be executed by one thread at a


time. Every other


thread wanting to access this method will be blocked during


this time (well,


basically). So you want to try to keep the synchonized blocks


as small as


possible.

Having said that I wonder weather performance is an issue in


the singleton


vs only-static discussion. Is there a significant difference in


execution


speed? After all one has to make one additional method call


every time when


accessing a singleton method (the getInstance() which is  synchronized,
too). And since we're off topic anyway: is a call to a static


method faster


than a "normal" one to an object (well, I mean the overhead


from the method


call, not the execution speed of the method body ... )?


Cheers
Tobi



From: "Erik Price" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <[EMAIL PROTECTED]>
Sent: Wednesday, January 29, 2003 1:46 PM
Subject: Re: about singletons (ot)





Mike Jackson wrote:



The difference is that if you use a singleton there's one instance.  If
everything
is static then you only have one copy.  Usually when you use a


singleton


it&

RE: about singletons (ot)

[Mike Jackson]

Hmm, I wish I'd been paying attention to the list, but basically yes.  You
get finer control by using synchronized code blocks.  Really the major
reason is that you in most cases don't really need to synchronize the entire
method, only small portions of the code.  For example:

protected static Object lock = new Object();
protected static int nextId = 1;

public int getNextId() {
int id = -1;
synchronized( lock ) {
id = nextId;
nextId++;
}
return id;
}

public void setNextId( int i ) {
synchronized( lock ) {
nextId = i;
}
}

As you can see we've got protection for the variable we care about, namely
"nextId".  And we've got it setup such that you can have threads accessing
nextId both in the
getNext and setNext methods.  Now you're probably saying that you could use
the synchronized statement on the methods here.  The answer to that is nope,
when you synchronize the method you're synchronizing on "this", since the
goal is to protect a static variable you're not going to want to do that.

Now even if the nextId wasn't static, you have to consider that you might be
doing other work in the methods.  Work that doesn't need to be synchronized.
For example we might have something like this:

protected int id = 1;

public synchronized void spin( int i )
/* start crit section */
int i, max = id;
id++;
/* end crit section */
for ( int i = 0; i < max; i++ ) {
;
}
}

Ok, so this code is safe, but is it efficent?  We're blocking threads from
entering which will protect the "id" variable, but we'll be taking time
outside the crit section which will also be protected.  Clearly we don't
really want to do this.  A better way to do this is:

protected Object lock = new Object();
protected int id = 1;

public synchronized void spin( int i )
int i, max;
/* start crit section */
synchronized( lock ) {
max = id;
id++;
}
/* end crit section */
for ( int i = 0; i < max; i++ ) {
;
}
}

We're still protecting the crit section, but we aren't impeding other
threads from entering and even completing their pass through the method
prior to our finish.

However sucky examples and all making code thread safe is a lot of work.
There's some "recipes" out there for generating thread safe code, but quite
frankly I don't remember them any more.  But there's some really good books
that we mentioned by other people, the addison westley book is good, and the
o'reilly threads book is good.

--mikej
-=-
mike jackson
[EMAIL PROTECTED]

> -Original Message-----
> From: Erik Price [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, January 29, 2003 12:26 PM
> To: Tomcat Users List
> Subject: Re: about singletons (ot)
>
>
> So you mean that the original author (mike jackson) was saying that he
> used synchronized code blocks to apply a finer level of detail in
> specifying what is synchronized and what isn't, as opposed to just
> declaring an entire method synchronized?
>
> I understand that synchronization implies a performance penalty, but I
> wasn't sure what the advantage to using synchronized blocks over
> synchronized methods was.
>
>
> Erik
>
>
>
>
> Tobias Dittrich wrote:
> > The reason why you don't want to use synchronized methods is that a
> > synchronized block can only be executed by one thread at a
> time. Every other
> > thread wanting to access this method will be blocked during
> this time (well,
> > basically). So you want to try to keep the synchonized blocks
> as small as
> > possible.
> >
> > Having said that I wonder weather performance is an issue in
> the singleton
> > vs only-static discussion. Is there a significant difference in
> execution
> > speed? After all one has to make one additional method call
> every time when
> > accessing a singleton method (the getInstance() which is  synchronized,
> > too). And since we're off topic anyway: is a call to a static
> method faster
> > than a "normal" one to an object (well, I mean the overhead
> from the method
> > call, not the execution speed of the method body ... )?
> >
> >
> > Cheers
> > Tobi
> >
> >
> >
> > From: "Erik P

RE: about singletons (ot)

[WATKIN-JONES,ADAM (HP-UnitedKingdom,ex1)]

Basically yes. Much less code than you normally would think needs to be
declared synchronized.  Maybe someone can post a link to a good guide to
thread synchronization - personally I only can recommend the O'Reilly Java
Thread book but that's personal taste(!)




How about Concurrent Programming in Java, Doug Lea, Addison-Wesley?

I've only begun to work through it but already I'm finding it better than
other similar texts that I've encountered.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: about singletons (ot)

[Tobias Dittrich]

Basically yes. Much less code than you normally would think needs to be
declared synchronized.  Maybe someone can post a link to a good guide to
thread synchronization - personally I only can recommend the O'Reilly Java
Thread book but that's personal taste(!)

However - as you said, synchronization implies a performance penalty as
there will be some code around the synchronized block for lock checking etc.
This is regardless of where you put the synchronized flag - a method is just
as well a code block. So make sure not to change a single large synchronized
block (such as a whole method) for a patchwork of small synchronized blocks.
You might find your thread spending the gained time (for not having to wait
for locks to become free) in synchronization management code.

Tobi



- Original Message -
From: "Erik Price" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <[EMAIL PROTECTED]>
Sent: Wednesday, January 29, 2003 9:26 PM
Subject: Re: about singletons (ot)


> So you mean that the original author (mike jackson) was saying that he
> used synchronized code blocks to apply a finer level of detail in
> specifying what is synchronized and what isn't, as opposed to just
> declaring an entire method synchronized?
>
> I understand that synchronization implies a performance penalty, but I
> wasn't sure what the advantage to using synchronized blocks over
> synchronized methods was.
>
>
> Erik
>
>
>
>
> Tobias Dittrich wrote:
> > The reason why you don't want to use synchronized methods is that a
> > synchronized block can only be executed by one thread at a time. Every
other
> > thread wanting to access this method will be blocked during this time
(well,
> > basically). So you want to try to keep the synchonized blocks as small
as
> > possible.
> >
> > Having said that I wonder weather performance is an issue in the
singleton
> > vs only-static discussion. Is there a significant difference in
execution
> > speed? After all one has to make one additional method call every time
when
> > accessing a singleton method (the getInstance() which is  synchronized,
> > too). And since we're off topic anyway: is a call to a static method
faster
> > than a "normal" one to an object (well, I mean the overhead from the
method
> > call, not the execution speed of the method body ... )?
> >
> >
> > Cheers
> > Tobi
> >
> >
> >
> > From: "Erik Price" <[EMAIL PROTECTED]>
> > To: "Tomcat Users List" <[EMAIL PROTECTED]>
> > Sent: Wednesday, January 29, 2003 1:46 PM
> > Subject: Re: about singletons (ot)
> >
> >
> >
> >>
> >>Mike Jackson wrote:
> >>
> >>>The difference is that if you use a singleton there's one instance.  If
> >>>everything
> >>>is static then you only have one copy.  Usually when you use a
singleton
> >>>it's to
> >>>control access to some resource, the intent is that you use the
> >
> > singleton
> >
> >>>and some
> >>>synchronized calls (note I don't mean synchronized methods, but
> >
> > synchronized
> >
> >>>code
> >>>blocks) to control threads using that resource.
> >>
> >>Why could you not use synchronized methods?
> >>
> >>
> >>
> >>Erik


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: about singletons (ot)

[Felipe Schnack]

  Strangely enough, a long time ago someone said me that static method
were slower to execute than normal ones... this makes no sense to me,
but anyone knows if this is true?
  Personally, I freak out when I see synch'd code where it can be
avoided :-))

On Wed, 2003-01-29 at 18:17, Tobias Dittrich wrote:
> 
> The reason why you don't want to use synchronized methods is that a
> synchronized block can only be executed by one thread at a time. Every other
> thread wanting to access this method will be blocked during this time (well,
> basically). So you want to try to keep the synchonized blocks as small as
> possible.
> 
> Having said that I wonder weather performance is an issue in the singleton
> vs only-static discussion. Is there a significant difference in execution
> speed? After all one has to make one additional method call every time when
> accessing a singleton method (the getInstance() which is  synchronized,
> too). And since we're off topic anyway: is a call to a static method faster
> than a "normal" one to an object (well, I mean the overhead from the method
> call, not the execution speed of the method body ... )?
> 
> 
> Cheers
> Tobi
> 
> 
> 
> From: "Erik Price" <[EMAIL PROTECTED]>
> To: "Tomcat Users List" <[EMAIL PROTECTED]>
> Sent: Wednesday, January 29, 2003 1:46 PM
> Subject: Re: about singletons (ot)
> 
> 
> >
> >
> > Mike Jackson wrote:
> > > The difference is that if you use a singleton there's one instance.  If
> > > everything
> > > is static then you only have one copy.  Usually when you use a singleton
> > > it's to
> > > control access to some resource, the intent is that you use the
> singleton
> > > and some
> > > synchronized calls (note I don't mean synchronized methods, but
> synchronized
> > > code
> > > blocks) to control threads using that resource.
> >
> > Why could you not use synchronized methods?
> >
> >
> >
> > Erik
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
-- 

Felipe Schnack
Analista de Sistemas
[EMAIL PROTECTED]
Cel.: (51)91287530
Linux Counter #281893

Centro Universitário Ritter dos Reis
http://www.ritterdosreis.br
[EMAIL PROTECTED]
Fone/Fax.: (51)32303341


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: about singletons (ot)

[Erik Price]

So you mean that the original author (mike jackson) was saying that he 
used synchronized code blocks to apply a finer level of detail in 
specifying what is synchronized and what isn't, as opposed to just 
declaring an entire method synchronized?

I understand that synchronization implies a performance penalty, but I 
wasn't sure what the advantage to using synchronized blocks over 
synchronized methods was.


Erik




Tobias Dittrich wrote:
The reason why you don't want to use synchronized methods is that a
synchronized block can only be executed by one thread at a time. Every other
thread wanting to access this method will be blocked during this time (well,
basically). So you want to try to keep the synchonized blocks as small as
possible.

Having said that I wonder weather performance is an issue in the singleton
vs only-static discussion. Is there a significant difference in execution
speed? After all one has to make one additional method call every time when
accessing a singleton method (the getInstance() which is  synchronized,
too). And since we're off topic anyway: is a call to a static method faster
than a "normal" one to an object (well, I mean the overhead from the method
call, not the execution speed of the method body ... )?


Cheers
Tobi



From: "Erik Price" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <[EMAIL PROTECTED]>
Sent: Wednesday, January 29, 2003 1:46 PM
Subject: Re: about singletons (ot)





Mike Jackson wrote:


The difference is that if you use a singleton there's one instance.  If
everything
is static then you only have one copy.  Usually when you use a singleton
it's to
control access to some resource, the intent is that you use the


singleton


and some
synchronized calls (note I don't mean synchronized methods, but


synchronized


code
blocks) to control threads using that resource.


Why could you not use synchronized methods?



Erik




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: about singletons (ot)

[Tobias Dittrich]

The reason why you don't want to use synchronized methods is that a
synchronized block can only be executed by one thread at a time. Every other
thread wanting to access this method will be blocked during this time (well,
basically). So you want to try to keep the synchonized blocks as small as
possible.

Having said that I wonder weather performance is an issue in the singleton
vs only-static discussion. Is there a significant difference in execution
speed? After all one has to make one additional method call every time when
accessing a singleton method (the getInstance() which is  synchronized,
too). And since we're off topic anyway: is a call to a static method faster
than a "normal" one to an object (well, I mean the overhead from the method
call, not the execution speed of the method body ... )?


Cheers
Tobi



From: "Erik Price" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <[EMAIL PROTECTED]>
Sent: Wednesday, January 29, 2003 1:46 PM
Subject: Re: about singletons (ot)


>
>
> Mike Jackson wrote:
> > The difference is that if you use a singleton there's one instance.  If
> > everything
> > is static then you only have one copy.  Usually when you use a singleton
> > it's to
> > control access to some resource, the intent is that you use the
singleton
> > and some
> > synchronized calls (note I don't mean synchronized methods, but
synchronized
> > code
> > blocks) to control threads using that resource.
>
> Why could you not use synchronized methods?
>
>
>
> Erik


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: about singletons (ot)

[Erik Price]

Mike Jackson wrote:

The difference is that if you use a singleton there's one instance.  If
everything
is static then you only have one copy.  Usually when you use a singleton
it's to
control access to some resource, the intent is that you use the singleton
and some
synchronized calls (note I don't mean synchronized methods, but synchronized
code
blocks) to control threads using that resource.


Why could you not use synchronized methods?



Erik


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: about singletons (ot)

[Daniel Brown]

That would depend on if the constructor actually *does* something.

If it needs to set up a connection pool, parse an XML configuration file, or
whatever, then you have the choice of,

- doing this once, reliably, in the constructor, or
- making sure that every single last static method checks to see if this has
already been done.

If the singleton needs to acquire, or process a resource in order to
function, then 'construction is resource acquisition' should save a lot of
typing and bug hunting.

Dan.

> -Original Message-
> From: Felipe Schnack [mailto:[EMAIL PROTECTED]]
> Sent: 28 January 2003 21:56
> To: Tomcat Users List
> Subject: about singletons (ot)
>
>
>   These days I was thinking
>   It's not so uncommon to have uses for singleton classes in our
> everyday lives. Normally we do that implementing a class that have its
> constructor as private, so no one can instantiate it, and a
> getInstance() method or something like it. We wouldn't have the same
> kind of behavior if we simply declare all class methods/fields as
> static?


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: about singletons (ot)

[Ralph Einfeldt]

Although possible it has several drawbacks.

- Singletons that are just a class will never 
  be garbage collected. Instance singletons can 
  be, as soon as there is no reference to it.
  
- If you want to pass that singleton around, you loose 
  typesafty. (The singleton is just instance of 
  java.lang.Class and nothing else)

- You loose flexibility.
  E.g. Different singletons that implement the same 
  interface, and objects that do something with 
  instances that implement this interface.
  
- There can be several versions of the same class
  as each classloader can have its own version.
  (This can also happen, with your other approach

- You cant define interfaces for class that apply to
  the class. (Interfaces apply only to the instances
  of the class)

Not that I recommend not to do it, but when you do it
be aware of this drawbacks. (Some of the drawbacks can 
be overcome through the implementation of the class, 
but that is additional coding)


> -Original Message-
> From: Felipe Schnack [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, January 28, 2003 10:56 PM
> To: Tomcat Users List
> Subject: about singletons (ot) 
> 
> Normally we do that implementing a class that have its
> constructor as private, so no one can instantiate it,
> and a getInstance() method or something like it. We 
> wouldn't have the same kind of behavior if we simply 
> declare all class methods/fields as static?
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: about singletons (ot)

[Mike Jackson]

Me too, we learn by doing... :)

That's also the reason that I follow the pattern as it is stated now, rather
than thinking I can make it a little different.

--mikej
-=-
mike jackson
[EMAIL PROTECTED]

> -Original Message-
> From: Larry Meadors [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, January 28, 2003 4:09 PM
> To: [EMAIL PROTECTED]
> Subject: RE: about singletons (ot)
>
>
> I would agree.
>
> We had a static class and we thought it would work great...it turned out
> that we ended up rewriting much of it to use the getInstance() type of
> interface - it is just so much more flexible if you *EVER* need to
> change stuff.
>
> Larry
>
> >>> [EMAIL PROTECTED] 01/28/03 16:08 PM >>>
> The difference is that if you use a singleton there's one instance.  If
> everything
> is static then you only have one copy.  Usually when you use a singleton
> it's to
> control access to some resource, the intent is that you use the
> singleton
> and some
> synchronized calls (note I don't mean synchronized methods, but
> synchronized
> code
> blocks) to control threads using that resource.  You could probably
> implement
> a similiar system if everything were static, but I wouldn't want to try
> (it's more
> work than you think).
>
> --mikej
> -=-
> mike jackson
> [EMAIL PROTECTED]
>
> > -Original Message-
> > From: Felipe Schnack [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, January 28, 2003 1:56 PM
> > To: Tomcat Users List
> > Subject: about singletons (ot)
> >
> >
> >   These days I was thinking
> >   It's not so uncommon to have uses for singleton classes in our
> > everyday lives. Normally we do that implementing a class that have its
> > constructor as private, so no one can instantiate it, and a
> > getInstance() method or something like it. We wouldn't have the same
> > kind of behavior if we simply declare all class methods/fields as
> > static?
> >
> > --
> >
> > Felipe Schnack
> > Analista de Sistemas
> > [EMAIL PROTECTED]
> > Cel.: (51)91287530
> > Linux Counter #281893
> >
> > Centro Universitßrio Ritter dos Reis
> > http://www.ritterdosreis.br
> > [EMAIL PROTECTED]
> > Fone/Fax.: (51)32303341
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> >
>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: about singletons (ot)

[Larry Meadors]

I would agree. 

We had a static class and we thought it would work great...it turned out
that we ended up rewriting much of it to use the getInstance() type of
interface - it is just so much more flexible if you *EVER* need to
change stuff.

Larry

>>> [EMAIL PROTECTED] 01/28/03 16:08 PM >>>
The difference is that if you use a singleton there's one instance.  If
everything
is static then you only have one copy.  Usually when you use a singleton
it's to
control access to some resource, the intent is that you use the
singleton
and some
synchronized calls (note I don't mean synchronized methods, but
synchronized
code
blocks) to control threads using that resource.  You could probably
implement
a similiar system if everything were static, but I wouldn't want to try
(it's more
work than you think).

--mikej
-=-
mike jackson
[EMAIL PROTECTED]

> -Original Message-
> From: Felipe Schnack [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, January 28, 2003 1:56 PM
> To: Tomcat Users List
> Subject: about singletons (ot)
>
>
>   These days I was thinking
>   It's not so uncommon to have uses for singleton classes in our
> everyday lives. Normally we do that implementing a class that have its
> constructor as private, so no one can instantiate it, and a
> getInstance() method or something like it. We wouldn't have the same
> kind of behavior if we simply declare all class methods/fields as
> static?
>
> --
>
> Felipe Schnack
> Analista de Sistemas
> [EMAIL PROTECTED]
> Cel.: (51)91287530
> Linux Counter #281893
>
> Centro Universitßrio Ritter dos Reis
> http://www.ritterdosreis.br
> [EMAIL PROTECTED]
> Fone/Fax.: (51)32303341
>
>
> --
> To unsubscribe, e-mail:
> 
> For additional commands, e-mail:
> 
>



--
To unsubscribe, e-mail:  

For additional commands, e-mail:




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: about singletons (ot)

[Mike Jackson]

The difference is that if you use a singleton there's one instance.  If
everything
is static then you only have one copy.  Usually when you use a singleton
it's to
control access to some resource, the intent is that you use the singleton
and some
synchronized calls (note I don't mean synchronized methods, but synchronized
code
blocks) to control threads using that resource.  You could probably
implement
a similiar system if everything were static, but I wouldn't want to try
(it's more
work than you think).

--mikej
-=-
mike jackson
[EMAIL PROTECTED]

> -Original Message-
> From: Felipe Schnack [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, January 28, 2003 1:56 PM
> To: Tomcat Users List
> Subject: about singletons (ot)
>
>
>   These days I was thinking
>   It's not so uncommon to have uses for singleton classes in our
> everyday lives. Normally we do that implementing a class that have its
> constructor as private, so no one can instantiate it, and a
> getInstance() method or something like it. We wouldn't have the same
> kind of behavior if we simply declare all class methods/fields as
> static?
>
> --
>
> Felipe Schnack
> Analista de Sistemas
> [EMAIL PROTECTED]
> Cel.: (51)91287530
> Linux Counter #281893
>
> Centro Universitário Ritter dos Reis
> http://www.ritterdosreis.br
> [EMAIL PROTECTED]
> Fone/Fax.: (51)32303341
>
>
> --
> To unsubscribe, e-mail:
> 
> For additional commands, e-mail:
> 
>



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: about singletons (ot)

[Jon Wingfield]

Did someone say Booch utility?

http://www.javaworld.com/javaworld/jw-04-1999/jw-04-toolbox.html

see page 2. Actually, this entire set of articles on threading is excellent.

Felipe Schnack wrote:

  These days I was thinking
  It's not so uncommon to have uses for singleton classes in our
everyday lives. Normally we do that implementing a class that have its
constructor as private, so no one can instantiate it, and a
getInstance() method or something like it. We wouldn't have the same
kind of behavior if we simply declare all class methods/fields as
static?







--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: about singletons (ot)

[Cees van de Griend]

On Tuesday 28 January 2003 22:56, Felipe Schnack wrote:
>   These days I was thinking
>   It's not so uncommon to have uses for singleton classes in our
> everyday lives. Normally we do that implementing a class that have its
> constructor as private, so no one can instantiate it, and a
> getInstance() method or something like it. We wouldn't have the same
> kind of behavior if we simply declare all class methods/fields as
> static?

No, you don't. In this case you are able to create multiple instances of this 
class. Sure, you can create one, but is is not enforced.

With a singleton, only one instance of the class can be created.

Regards,
Cees.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: