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.
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 -
posted 11 years ago
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 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.
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.