Win a copy of Mesos in Action this week in the Cloud/Virtualizaton forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Accessing one singleton across JVMs

 
Arpit Sharma
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
suppose i am having one singleton object in one jvm ,how do i maintain the same copy of singleton across different JVMs
 
Martijn Verburg
author
Bartender
Posts: 3275
5
Eclipse IDE Java Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This Sun Thread might help you out. But I have to ask, why are you wanting to do this?

Hope that helps!
 
Maneesh Godbole
Saloon Keeper
Posts: 11027
12
Android Eclipse IDE Google Web Toolkit Java Mac Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by ArpitSharma:
suppose i am having one singleton object in one jvm ,how do i maintain the same copy of singleton across different JVMs


Make a remote call to the "other JVM" and obtain a reference.
 
shiva shankar
Ranch Hand
Posts: 85
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Maneesh - Remote call is not a viable solution for this issue in distributed environment. I guess the quick answer would be you can't.
 
Maneesh Godbole
Saloon Keeper
Posts: 11027
12
Android Eclipse IDE Google Web Toolkit Java Mac Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by shiva shankar:
Maneesh - Remote call is not a viable solution for this issue in distributed environment.


Can you please explain why it is not a viable solution?
 
Rob Spoor
Sheriff
Pie
Posts: 20527
54
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Because each JVM has its own singleton instance. Static fields are only unique per Class instance, and using a different class loader (which will always be the case with a different JVM) will create a new Class instance, and therefore new static fields.
 
Maneesh Godbole
Saloon Keeper
Posts: 11027
12
Android Eclipse IDE Google Web Toolkit Java Mac Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Rob Prime:
Because each JVM has its own singleton instance. Static fields are only unique per Class instance, and using a different class loader (which will always be the case with a different JVM) will create a new Class instance, and therefore new static fields.


Hmm.
I was thinking of a different scenario.
You got some applications running on machine A and B.
When required these applications make a remote call to machine C and ask for the singleton instance.
That way the same instance would be shared accross multiple JVMs right?
 
tapeshwar sharma
Ranch Hand
Posts: 245
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Hmm.
I was thinking of a different scenario.
You got some applications running on machine A and B.
When required these applications make a remote call to machine C and ask for the singleton instance.
That way the same instance would be shared accross multiple JVMs right?

So, you are saying that only machine C has the Singleton while A and B don't?
In a distributed environment, usually we do not make a section of code stick to one single machine.Usually, the same code is shared across all the machines in a cluster.
I do not think that just to get a "Singleton" it is wise to configure your machines in a contrived scenario that you've presented.
 
Maneesh Godbole
Saloon Keeper
Posts: 11027
12
Android Eclipse IDE Google Web Toolkit Java Mac Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by prashant bhardwaj:

So, you are saying that only machine C has the Singleton while A and B don't?
I do not think that just to get a "Singleton" it is wise to configure your machines in a contrived scenario that you've presented.


No.
All machines have the same code. But A and B ask C for the instance.


I do not think that just to get a "Singleton" it is wise to configure your machines in a contrived scenario that you've presented.

The point here is not to "get" a singleton but to share it accross JVMs
 
tapeshwar sharma
Ranch Hand
Posts: 245
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

All machines have the same code. But A and B ask C for the instance.

So, you mean hard code the IP or what?
 
tapeshwar sharma
Ranch Hand
Posts: 245
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Actually, this:

All machines have the same code. But A and B ask C for the instance.


contradicts with this:

The point here is not to "get" a singleton but to share it accross JVMs


both are your statements in a single post.
 
Maneesh Godbole
Saloon Keeper
Posts: 11027
12
Android Eclipse IDE Google Web Toolkit Java Mac Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ok.
My last reply on this subject.

How A and B figure out the details for C is irrelevant to this discussion. Similar stuff is done every day by lots of people (think web.xml or config file or properties or anything that catches your fancy).

Idea is to share the same singleton instance between multiple JVMs.
Does it make sense to code multiple times? (in my scenario, minimum two)? No. So same code is deployed on A B and C.

Now the singleton to be shared is the one on C. So A and B need to be configured so that they ask C. For configuration one can choose any of the above.

So whenever the singleton instance is required, everybody asks C.
 
tapeshwar sharma
Ranch Hand
Posts: 245
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hold on for a moment please.

So whenever the singleton instance is required, everybody asks C

How's this different from "getting" the instance?


Similar stuff is done every day by lots of people (think web.xml or config file or properties or anything that catches your fancy).

I'd like to be educated about it.How one machine(say A) in a cluster would identify another machine (C in this case) to make a call for a Singleton ?
 
Paul Clapham
Sheriff
Posts: 21107
32
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by prashant bhardwaj:
I'd like to be educated about it.How one machine(say A) in a cluster would identify another machine (C in this case) to make a call for a Singleton ?
Well, A would be told where C is, perhaps by some configuration file or by a JNDI lookup or something. I don't see why this is such a difficult business. Nobody complains about having to tell the database clients where the database is located, so why should it be different for this C resource?
 
tapeshwar sharma
Ranch Hand
Posts: 245
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Well, A would be told where C is, perhaps by some configuration file or by a JNDI lookup or something. I don't see why this is such a difficult business. Nobody complains about having to tell the database clients where the database is located, so why should it be different for this C resource?

To my limited knowledge, JNDI is also shared across machines in a cluster, at least in the environment that I work in .
If A,B and C all have the Singleton instance, then how do we tell JNDI to refer only to the one on machine C?
Database clients like a J2EE application are not clustered with the Database server.Its like accessing a service.
 
tapeshwar sharma
Ranch Hand
Posts: 245
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The point I am trying to make is that Singleton by the very definition means only one instance in a JVM(or classloader to be precise).
Accessing a service is not the same as sharing.
 
Campbell Ritchie
Sheriff
Pie
Posts: 48952
60
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
ArpitSharma: please read the important administrative private message I sent you a few minutes ago.

CR
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic