This week's giveaway is in the EJB and other Java EE Technologies forum. We're giving away four copies of EJB 3 in Action and have Debu Panda, Reza Rahman, Ryan Cuprak, and Michael Remijan on-line! See this thread for details.
Does the constructor need to be synch'd on DataFileAccess.class ? If two creates come along at the same time, is'nt there a chance that both of them could step into the create new RandomAccessFile logic?
i.e Thread 1 see's database = null and steps into if block Thread 1 gets suspended before it creates the RAF Thread2 comes along and sees that database = null, steps into if block
Besides, I'm not sure that the call to this line "database = new DvdFileAccess(dbPath);" in the construction of DvdDatabase whenever a new client connects to the server is safe since "database" is a static field. I would feel more comfortable if the "database" is somehow created once and never gets re-assigned.
Well, I am just preparing to start writing the code for my assignment. And I am bit confused with this constructor synchronization.
I guess you must be talking about some constructor modifying or accessing resources possibly used by another threads.
Because it would not make sense to synchronize a constructor since until the object is not completely constructed it is not subject to synchronization.
However it is possible to have a synchronization block within an constructor, as long as the lock is not based on the object itself (this).
Now, with the new locking mechanisms present in Tiger, I just wonder if all this constructor synchronization you're talking about might be a mistake.
I think it may be if it is based on the suposition that the constructor itself should be synchronized to avoid another threads to modify the state of the object while it is been constructed, because no other threads will have access to the object until it is actually constructed.
However if you refer to the posibility that another thread modifies, for instance, an static member variable, while the constructor is using it, than I thik it may be alright.
I haven't thought about this before for a singleton class. This is how I implement it.
Do you think synchronizing the getInstance() is good? I think it will prevent when 2 threads are calling that method and get to the line before the instance is assigned to a Data instance. But I haven't seen synchronization on the getInstance() anywhere in a singleton class. I wonder why.
For your class to follow the singleton pattern properly as per your example, you should make the constructor private. Unless I'm much mistaken, as you've written it, there's nothing stopping me coming along and doing:
And I've broken the singleton invariant.
Do you think synchronizing the getInstance() is good?
Yes - I think it's necessary. Otherwise you could get a race situation in which you end up with multiple instances again.
If you want a good reference, try Effective Java by Joshua Bloch - it has a great many useful tips.
Joined: Nov 09, 2003
Thanks, I will keep the synchronization on the getInstance().
I do have a private construtor in my code, forgot to cut and paste here.
I get a feeling I can always do it better and don't know when I am going to submit my assignment.