how would you keep the single instance of an object over multiple JVMs

[Anirudh Bhatnagr]

how would you keep the single instance of an object over multiple JVMs?

Make a singleton class object.
Serialize it ?
Wouldn't serialize ignore the static fields used for maintaining singleton behavior of the class?

Am I missing something here?
Is it possible first of all?

[Thakur Sachin Singh]

i think singleton class is enough for this.

[Rob Spoor]

Not really. Each JVM will have its own copy of the singleton object. You need a distributed solution; perhaps you can use RMI to do this.

[Seetharaman Venkatasamy]

Rob Spoor wrote:perhaps you can use RMI to do this.

well explanation . though it is a different instance right?

[Campbell Ritchie]

RMI serialises the object and sends it across a network (and across the innards of your computer is rather like "across a network"). I am not sure whether it is the same object or not.

This is however too difficult a question for "beginning", so I shall move it. Maybe JiG, maybe distributed? Let's try distributed, and the discussion might be moved again.

[Rob Spoor]

If the singleton instance is an RMI remote object itself, then no. You will need a couple of interfaces though; at least one for the RMI server, and one for the singleton instance. For instance:

interface SingletonServer extends Remote
{
    public Singleton getSingletonInstance() throws RemoteException;
}

interface Singleton extends Remote
{
    // singleton methods here; all should be declared to throw RemoteException
}

Perhaps you can even combine the two, making the RMI server object be the singleton object instead of returning it.

[Rob Spoor]

Campbell Ritchie wrote:RMI serialises the object and sends it across a network (and across the innards of your computer is rather like "across a network"). I am not sure whether it is the same object or not.

If I understand RMI correctly, if the object sent also implements Remote then it doesn't send an actual serialized copy but only uses the RMI mechanism. That would send method invocations through the network to the RMI server where the methods will be executed on the server.

This is however too difficult a question for "beginning", so I shall move it. Maybe JiG, maybe distributed? Let's try distributed, and the discussion might be moved again.

I think Distributed Java is a good place for this thread

[Campbell Ritchie]

Rob Spoor wrote:. . . I think Distributed Java is a good place for this thread

Thank you, Maybe I'll even remember to move it

[Anirudh Bhatnagr]

Sun Docs say :

Multiple Singletons in Two or More Virtual Machines
When copies of the Singleton class run in multiple VMs, an instance is created for each machine. That each VM can hold its own Singleton might seem obvious but, in distributed systems such as those using EJBs, Jini, and RMI, it's not so simple. Since intermediate layers can hide the distributed technologies, to tell where an object is really instantiated may be difficult.

For example, only the EJB container decides how and when to create EJB objects or to recycle existing ones. The EJB may exist in a different VM from the code that calls it. Moreover, a 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. Even an entity EJB can be saved through a persistence mechanism between calls, so that you have no idea what instance answers your method calls. (The primary key that is part of the entity bean spec is needed precisely because referential identity is of no use in identifying the bean.)

The EJB containers' ability to spread the identity of a single EJB instance across multiple VMs causes confusion if you try to write a Singleton in the context of an EJB. The instance fields of the Singleton will not be globally unique. Because several VMs are involved for what appears to be the same object, several Singleton objects might be brought into existence.

Systems based on distributed technologies such as EJB, RMI, and Jini should avoid Singletons that hold state. Singletons that do not hold state but simply control access to resources are also not appropriate for EJBs, since resource management is the role of the EJB container. However, in other distributed systems, Singleton objects that control resources may be used on the understanding that they are not unique in the distributed system, just in the particular VM.

Source : http://java.sun.com/developer/technicalArticles/Programming/singletons/

[William Brogden]

So we want one serializable object available/shared between multiple computers - only one of which can modify the object at any given time.

This sounds like a job for a JavaSpaces server.

I believe Gigaspaces still has a community edition.

Bill

[Gabriel Vince]

Hi,
it is a little bit tricky to have a common object instance shared between JVMs, some implementations may have shared memory, but it's not a common approach.
you could clarify what you want to achieve. Maybe it is a good idea to have a 'master singleton' and all clients may access the instance through some service facade (e.g. Rmi).
Or you need high availability? Look how j2ee servers do it (database or memory replication).
Good luck
Gabriel

[rahat mitul]

Check this ytsingleinstance.dll post ....

[Filip Trafisz]

If I were you I would look at some cache libraries. I don't have enough experience with those, I'm afraid, but maybe someone could clarify that - multiple jvm access the singleton from a cache. This way no 'extra' approach to singleton class is needed, only some additional code for cache appliance.

[Gaurav.S Singh]

Hi Anirudh Bhatnagr ,

You have to bind your program to port and need to implement a server which listen all other instance of your programme and if they are over multiple JVMs they need to communicate with each other in oreder keep there single instance to do this there is pre implemented java API

You can used Junique Api this solved your problem , as per my perception try this , Junique , This API is for class but you may implement this concept to keep single instance of a object also try to do your homework .

No need of worry and you need not to sustain a lot of your requests/effort to get help here some good Ranchers are always do best for you without embracing to any one :P

Good luck

Thanks

[ManojKumar Kumar]

By applying the singleton Design pattern we can create a single instance of an object.
Singleton Design pattern has only four steps
1. Create a class with a private constructor.
2. Create a private static refrence variable of type Class.
3. Create a public method whose return type shuld be the refrence variable.
4. Create the New class to make the instance of the class.
// you cannot able to make the instance of the superclass by invoking new keyword as its constructor is private and cannot be shown outside the class.
So to make the instance of that class you have to invoke Superclass name and then the method.
eg Dog.getFood();