• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

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

 
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Ranch Hand
Posts: 251
Hibernate Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
i think singleton class is enough for this.
 
Sheriff
Posts: 22783
131
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Likes 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 5575
Eclipse IDE Windows XP Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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


well explanation . though it is a different instance right?
 
Marshal
Posts: 79177
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Sheriff
Posts: 22783
131
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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:
Perhaps you can even combine the two, making the RMI server object be the singleton object instead of returning it.
 
Rob Spoor
Sheriff
Posts: 22783
131
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Marshal
Posts: 79177
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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/
 
Author and all-around good cowpoke
Posts: 13078
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Check this ytsingleinstance.dll post ....


 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Greenhorn
Posts: 5
Eclipse IDE Tomcat Server Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Greenhorn
Posts: 2
Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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();



 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic