This week's book giveaway is in the OCAJP forum.
We're giving away four copies of Programmer's Guide to Java SE 8 Oracle Certified Associate (OCA) and have Khalid A Mughal & Rolf W Rasmussen on-line!
See this thread for details.
Win a copy of Programmer's Guide to Java SE 8 Oracle Certified Associate (OCA) this week in the OCAJP forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Want to know why this is not a threading issue ?

 
Amandeep Singh
Ranch Hand
Posts: 850
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
if multiple threads are accessing front controller class.
then we are getting the instance of RequestContextFactory class, then calling methods on it.
So is this can cause a threading issue because the instance if RequestContextFactory is being
shared by all calling classes.

Context Object Factory


RequestContextFactory
 
Sebastian Janisch
Ranch Hand
Posts: 1183
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The request object itself is thread-safe. You want to make sure that your RequestContextFactory class does not have any instance variables that can be affected by multiple threads accessing them.
 
Amandeep Singh
Ranch Hand
Posts: 850
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sebastian Janisch wrote:The request object itself is thread-safe. You want to make sure that your RequestContextFactory class does not have any instance variables that can be affected by multiple threads accessing them.


this is only my question, I am using the instance variable which is static. this instance variable is just used to give reference outside the class, to call its methods.
 
Sebastian Janisch
Ranch Hand
Posts: 1183
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You are using a Singleton here.

Your implementation is Thread-safe, but you should get used to only initialize when there is a need for it (saves valuable resources ;-) )

 
Amandeep Singh
Ranch Hand
Posts: 850
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Your approach is also fine which is the recommended approach.

See mine also it is fine because i am using static initialization which only happens when a class is loaded. And i am certain, this will be called definitely.
 
Nitesh Kant
Bartender
Posts: 1638
IntelliJ IDE Java MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sebastian Janisch wrote:You are using a Singleton here.

Your implementation is Thread-safe, but you should get used to only initialize when there is a need for it (saves valuable resources ;-) )



Well not really suggested. Doble checked locking is clever but broken
 
Paul Clapham
Sheriff
Posts: 21314
32
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sebastian Janisch wrote:You are using a Singleton here.

Your implementation is Thread-safe, but you should get used to only initialize when there is a need for it (saves valuable resources ;-) )


With this code, the singleton object will be created the first time the getInstance() method is called. With Amandeep's code, the singleton object will be created the first time the class is loaded. This will almost certainly occur the first time the getInstance() method is called, so I don't see the benefit of the more complex (and iffy, as Nitesh said) code.
 
Mike Simmons
Ranch Hand
Posts: 3090
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Nitesh Kant wrote:
Sebastian Janisch wrote:You are using a Singleton here.

Your implementation is Thread-safe, but you should get used to only initialize when there is a need for it (saves valuable resources ;-) )



Well not really suggested. Doble checked locking is clever but broken

But the code above is not double-checked locking. There is only one "check", where we test if the instance variable is null. Double-checked locking has two such checks - one outside a sync block, and one inside. Two checks - that's why it's called "double-checked". One check is not "double checked locking". At all.

Instead, the above code is the standard, correct way to implement a lazy singleton, prior to JDK 5. After JDK 5, you can also use double-checked locking, as long as you declare the "instance" variable as volatile. It works now.

Having said that, it's not at all clear that either form of lazy initialization is needed here. A simple non-lazy singleton probably works fine, and is much simpler. If laziness is really needed, it's still unlikely that double-checked locking is really needed, as that's a relic from the days when synchronization was much slower than it is today. The performance difference is in most cases inconsequential, so you might as well use the simplest code that works.

 
Nitesh Kant
Bartender
Posts: 1638
IntelliJ IDE Java MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Mike Simmons wrote:But the code above is not double-checked locking.


Gosh .. i was dreaming i guess. Sorry guys.
 
Consider Paul's rocket mass heater.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic