I intend to make Singleton (in the classic sense, NOT Singleton EJBs) that should be created and accessed only by EJBs (NOT by Web components) archived in the same .jar, and deployed on the same application server (so I suppose that there should be in the same JVM). In EJB Design Patterns book (last sentence on page 201), I found that there will be one instance per class loader "(each deployed ejb-jar will have its own separate class loader.. )". So if I understand well, my solution should be allowed and should work (meaning no multiple versions of the same instance)?
Is there problem with J2EE server garbage collection of such Singleton?

Solution to use entity bean, instead of Singleton, is not acceptable

Tnx
Zeljko

Well the common way is to keep a reference for your singelton instance in a static member variable. This way GC will not touch your object.

e.g.

public class MySingleton
{
  private static MySingleton instance;
  private static Object instanceSyncPoint = new Object();

  private MySingleton()
  {
   //...
  }
  
  public static MySingleton getInstance()
  {
    if (instance == null)
    {
      synchronized(instanceSyncPoint)
      {
        if (instance == null)
        {
          instance = new MySingleton();
        }
      }
    }
    return instance;
  }
}

I found that even this is not reliable (article http://www.jguru.com/faq/view.jsp?EID=124425).

Also the question is, will this work inside EJB Container because "single EJB can be instantiated simultaneously in several VMs. For a stateless session bean, multiple calls to what appears, to your code, to be one instance could actually be calls to different instances on different VMs." (article http://www.javaworld.com/javaworld/jw-01-2001/jw-0112-singleton-p2.html)

I found that even this is not reliable (article http://www.jguru.com/faq/view.jsp?EID=124425)

Thsi example will generate NullPointerExc. because the author forgot to initialize syncObject_, e.g.:
private static Object syncObject_;

.Also the question is, will this work inside EJB Container because "single EJB can be instantiated simultaneously in several VMs. For a stateless session bean, multiple calls to what appears, to your code, to be one instance could actually be calls to different instances on different VMs." (article http://www.javaworld.com/javaworld/jw-01-2001/jw-0112-singleton-p2.html)

In your original question you have specifically asked for Singleton in ONE JVM.
For singele JVM I think it is the one of the best solutions I have provided.

Have read "Double-Checked Locking is Broken" - very interesing...

In such case, I would have the following singleton (that eliminates "Double-Checked Locking" problem:

public class MySingleton
{
  private static MySingleton instance;

  private MySingleton()
  {
   //...
  }
  
  private static synchronized MySingleton createInstance()
  {
    instance = new MySingleton();
  }

  public static MySingleton getInstance()
  {
    if (instance == null)
    {
      createInstance();
    }
    return instance;
  }
}

That's still not thread save since the new operator doesn't define when it's pointer is returned. In other words: instance may have been assigned before the object is initialized.
------
why do you want to lazy load anyway?

That's still not thread save since the new operator doesn't define when it's pointer is returned. In other words: instance may have been assigned before the object is initialized. ------why do you want to lazy load anyway?

Lazy load is good for situations when the singleton class is not required all the time. For example it could be activated ONLY in some particular user workflow.

Can you also explain more why do you think synchronized static method is not thread safe when it initializes an instance?

Lazy load is good for situations when the singleton class is not required all the time. For example it could be activated ONLY in some particular user workflow.Can you also explain more why do you think synchronized static method is not thread safe when it initializes an instance?

First off all, you are missing a null check in your synchronized method. It is possible your 'Singleton' returns multiple single instances. Consider what would happen if two threads accessed the instance method and your instance is still null. Two different instances could be created. Furthermore, as described before, the return time of the new operator is undefined.

Ever looked at static loading and when static members get initialized?

Oops I forgot to add an extra check

public class MySingleton
{
  private static MySingleton instance;

  private MySingleton()
  {
   //...
  }
  
  private static synchronized MySingleton createInstance()
  {
    if (instance == null)
    {
      instance = new MySingleton();
    }
  }

  public static MySingleton getInstance()
  {
    if (instance == null)
    {
      createInstance();
    }
    return instance;
  }
}

Since this check is happening inside of SYNC method I assume it is thread safe. Second check in in synchronized method NOT in the block...(as authors in "Double-Checked Locking is Broken" point out, http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html)

don't assume, because it's not thread safe. Though it's not likely it will get you into trouble either. It's the same old new operator problem.

don't assume, because it's not thread safe. Though it's not likely it will get you into trouble either. It's the same old new operator problem.

But the article http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html has its example for safe multi-thread code:

------------------------------------
// Correct multithreaded version
class Foo {
  private Helper helper = null;
  public synchronized Helper getHelper() {
    if (helper == null)
        helper = new Helper();
    return helper;
    }
  // other functions and members...
  }
------------------------------------
Based on it, I think it is safe to have "new" operator in synchronized method...
Don't you think?

No, there is a difference. synchronize locks the entire object, but there is offcourse a difference when you lock from inside the object or lock from outside the object. You are now locking from inside the object.

why do you want to lazy load anyway?

You are right, I don't need it. But that wasn't my question at all. My concrete problem is:

if I have EJBs in the same ejb-jar does this mean that there will be always only one class-loader (single JVM), what guarantees that there will be only one Singleton instance (available to all EJBs, and not lazy instantiated)

Ruslan, thank You for trying to help me :)

In your original question you have specifically asked for Singleton in ONE JVM.For singele JVM I think it is the one of the best solutions I have provided.

Yes, my question was for Singleton in the single JVM, but in case that it is true that EJBs from the SAME EJB-JAR will be ALWAYS in the same JVM. Is this correct?