(absence of) singletons

[Leo Simons <ma...@leosimons.com>]

Just saw the second post on the topic today.
Wondering why there are none in the framework...
should we perhaps have an

public interface SingletonService extends Service
{
	public SingletonService getInstance();
}
public abstract class AbstractSingletonService implements SingletonService
{
	static SingletonService m_instance = null;

	private AbstractSingletonService()
	{
	}
	public static SingletonService getInstance()
	{
		if( m_instance == null )
			m_instance = createInstance();
		return m_instance;
	}
	protected abstract static SingletonService createInstance();
}
public class SomeSingletonService extends AbstractSingletonService
{
	protected static SomeSingletonService createInstance()
	{
		return new SomeSingletonService();
	}
}

...it is easy to modify phoenix so you can
have per-application singleton services like
this.

thoughts? votes? bad idea?

- Leo

---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org

Re: (absence of) singletons

[Peter Donald <do...@apache.org>]

On Mon, 3 Sep 2001 01:48, Leo Simons wrote:
> > > thoughts? votes? bad idea?
> >
> > Difficult.
> >
> > 1) What is a singleton? Is it one instance per classloader, one per JVM
> > or one per a cluster of machines?
>
> once per classloader. If you want to go beyond that you need another
> mechanism (it's just not possible within Java otherwise, as you need
> "static").

The problem then becomes ... which ClassLoader ;) Because in theory you could 
have several shared or in hierarchies it becomes difficult to determin 
certain behaviour in different environments. ie is it in base, shared, 
api-layer, app layer, ContextClassLoader (which could be different again).

In my opinion Singletons are a programatic shortcut. They are very prevelent 
in what I call stage 1/2 frameworks but unless they are performing "system" 
services then they are probably a kludge (though I have heard many claim that 
even system services such as security/System.* etc are also kludges).

Instead of creating singletons in an Avalon-style system I would just create 
one instance and then place it with the same name in all ComponentManagers or 
in a "root" component manager as suggested.

In a way I think I am glad that Avalon makes it difficult to use singletons 
because it makes for much more easily modifiable (and scalable) architectures.

-- 
Cheers,

Pete

---------------------------------------------------------
Clarke's Third Law: "Any technology distinguishable from 
magic is insufficiently advanced".
---------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org

Re: (absence of) singletons

[Paul Hammant <Pa...@yahoo.com>]

One more problem with Singleton -

As mentioned in this thread, they are per classloader (or visible in a 
classloader hierarchy).  At the moment phoenix places all blocks for one 
SAR file in one classloader.  There are good architectural and security 
reasons that we might want to change that in the future.  If we do, some 
singletons become invisible to some blocks, just because a user upgraded 
Avalon.

- Paul


---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org

RE: (absence of) singletons

[Leo Sutic <le...@inspireinfrastructure.com>]

> > 1) What is a singleton? Is it one instance per classloader, one
> per JVM or
> > one per a cluster of machines?
>
> once per classloader. If you want to go beyond that you need another
> mechanism (it's just not possible within Java otherwise, as you need
> "static").
>
> > 2) This is similar to the root component manager issue (Berin
> > brought up the
> > fact that there are some security risks involved and that JNDI would be
> > safer), and I think a solution within that framework would be better. It
> > would also answer the first question.
>
> JNDI should be optional, methinks. So a JNDI-stored single-instance-only-
> objects-framework should be only ever an optional part.

Then the following is possible:

Per CL:

Component implements ThreadSafe and passes all messages on to a private
static final instance:

public class CLSingleton implements ThreadSafe {

  private static final CLSingletonService instance = new CLSingletonService
();

  public void doStuff() {
    instance.doStuff();
  }
}


Per Cluster:

Component is poolable and looks up the remote object in initialize() and
recycle():

public class ClusterSingleton implements Poolable, Recyclable,
Initializable, Disposable {

  private ClusterSingletonService instance = null;

  public void doStuff() {
    instance.doStuff();
  }

  public void initialize () {
    instance = doJNDILookup ();
  }

  public void dispose () {
    disposeInstance ();
  }

  public void recycle () {
    // To avoid memory leaks via RMI, dispose and lookup the JNDI instance.
  }
}

So both types of singletons are possible without a new Singleton interface.

/LS


---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org

RE: (absence of) singletons

[Leo Simons <ma...@leosimons.com>]

> > thoughts? votes? bad idea?
>
> Difficult.
>
> 1) What is a singleton? Is it one instance per classloader, one per JVM or
> one per a cluster of machines?

once per classloader. If you want to go beyond that you need another
mechanism (it's just not possible within Java otherwise, as you need
"static").

> 2) This is similar to the root component manager issue (Berin
> brought up the
> fact that there are some security risks involved and that JNDI would be
> safer), and I think a solution within that framework would be better. It
> would also answer the first question.

JNDI should be optional, methinks. So a JNDI-stored single-instance-only-
objects-framework should be only ever an optional part.

If you store a singleton within JNDI to make it a singleton, you're making
sure the object only exists on a single computer and are obtaining remote
references to that object. Sounds like you could also use RMI to export the
object. Or SOAP. Or JMX. Or (de-)serialization to a central location.
When you consider that, you still need a marker interface indicating some
component should be a system-wide singleton and that the CM should get it
from some configured remote source. And a management abstraction from all
those tools. And more configuration.
Probably better to start with the std per-CL-singleton option...

...just thoughts.

- Leo


---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org

RE: (absence of) singletons

[Leo Sutic <le...@inspireinfrastructure.com>]

> -----Original Message-----
> From: Leo Simons [mailto:mail@leosimons.com]
> Sent: den 2 september 2001 17:25
> To: Avalon Development
> Subject: (absence of) singletons
>
> thoughts? votes? bad idea?

Difficult.

1) What is a singleton? Is it one instance per classloader, one per JVM or
one per a cluster of machines?

2) This is similar to the root component manager issue (Berin brought up the
fact that there are some security risks involved and that JNDI would be
safer), and I think a solution within that framework would be better. It
would also answer the first question.

/LS


---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org