Granny's Programming Pearls
"inside of every large program is a small program struggling to get out"
JavaRanch.com/granny.jsp
The moose likes Threads and Synchronization and the fly likes Want to know why this is  not a threading issue ? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "Want to know why this is  not a threading issue ?" Watch "Want to know why this is  not a threading issue ?" New topic
Author

Want to know why this is not a threading issue ?

Amandeep Singh
Ranch Hand

Joined: Jul 17, 2008
Posts: 844
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


SCJP 1.4, SCWCD 5, SCBCD 5, OCPJWSD 5,SCEA-1, Started Assignment Part 2
My blog- http://rkydesigns.blogspot.com
Sebastian Janisch
Ranch Hand

Joined: Feb 23, 2009
Posts: 1183
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.


JDBCSupport - An easy to use, light-weight JDBC framework -
Amandeep Singh
Ranch Hand

Joined: Jul 17, 2008
Posts: 844
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

Joined: Feb 23, 2009
Posts: 1183
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

Joined: Jul 17, 2008
Posts: 844
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

Joined: Feb 25, 2007
Posts: 1638

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


apigee, a better way to API!
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18651
    
    8

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

Joined: Mar 05, 2008
Posts: 3018
    
  10
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

Joined: Feb 25, 2007
Posts: 1638

Mike Simmons wrote:But the code above is not double-checked locking.


Gosh .. i was dreaming i guess. Sorry guys.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Want to know why this is not a threading issue ?