permaculture playing cards*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Question about locking inside the constructor of file accessor Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Question about locking inside the constructor of file accessor" Watch "Question about locking inside the constructor of file accessor" New topic
Author

Question about locking inside the constructor of file accessor

Ravikiran Vishnuvajhala
Ranch Hand

Joined: Jan 11, 2006
Posts: 30
Hi,

I have the following question regarding synchronization inside the constructor of the class that accesses the data file -

I am planning to synchronize on an object as the first thing in the constructor that takes the data file name and path as input (I have made the default constructor private). The following is the logic I am using -



I am planning to read the header first and record numbers dynamically and store them intially and then allow any modifications to the file.

My question is - is it fine to synchronize the entire block of code that reads and stores the data in static variables (HashMap, Arrays)? Do you see any issues in this case? Another approach is to synchronize the block that is populating the variables (HashMap, Arrays), but I feel that it might lead to some issues like if one thread has already started modifying the data file, then other threads still trying to get the instance of DBAccess might corrupt these static variables in the class.

The instructions say that -

"Any attempt to lock a resource that is already locked should cause the current thread to give up the CPU, consuming no CPU cycles until the desired resource becomes available."

I don't think the above logic is violating this rule, but can you please let me know if my theory is correct or not? Or do you have any other suggestions?

Please help!. I searched the threads for this specific case and could not find anything. If it is already answered, please forward me the link.

Thanks
Ravi
[ March 20, 2007: Message edited by: Ravikiran Vishnuvajhala ]
Mihai Radulescu
Ranch Hand

Joined: Sep 18, 2003
Posts: 916

Hi Ravikiran

As far as I know you don't need to synchronize the constructors.
And also I don't see a reason for. On :
->the local mode - only one client read the database file - no danger
->the remote(or better multi user) mode - only the server read the database file and provides this information to its clients.

Regards M


SCJP, SCJD, SCWCD, OCPJBCD
Lucy Hummel
Ranch Hand

Joined: Apr 07, 2005
Posts: 232
Originally posted by Mihai Radulescu:

->the local mode - only one client read the database file - no danger


Hi Mihai,

It might be in the normal case that on one machine one GUI is started. But if SUN wants to test your code, they might start more than one GUI per machine.

I recomend to synchronized also the constructor.

But you know:
no risk no fun
Br, Lucy


----------------------------------<br />| SCJP, SCWCD, SCBCD, SCEA, SCJD |<br />----------------------------------
Nitesh Kant
Bartender

Joined: Feb 25, 2007
Posts: 1638

I think you should not release the lock in between a read and a write, simply because, in between the read and write you can not afford to let the data file changed. (I hope this DBAccess class is the only way to access the data file)
Yeah your logic is not voilating the rule you have specified and in fact is the full proof way of doing the same.

Hi Mihal,
What ravi is trying to do is to populate some static variables from the constructor, so in this case you need to synchronize the code in the constructor. However, if a constructor is only touching the instance level variables then there is no point in synchronizing the code.


apigee, a better way to API!
Mihai Radulescu
Ranch Hand

Joined: Sep 18, 2003
Posts: 916

Lucy

The sun will test your UI, this is right but sun must follow the specification also - the remove , I have in my specification something like :

Your programs must not require use of command line arguments other than the single mode flag, which must be supported.
....
The mode flag must be either "server", indicating the server program must run, "alone", indicating standalone mode, or left out entirely, in which case the network client and gui must run.


so, this is the ways how the must work.

Regards M.
Ravikiran Vishnuvajhala
Ranch Hand

Joined: Jan 11, 2006
Posts: 30
Hi All,

Thank you for your replies. I definitely think that we should synchronize the file object during instantiation and initialization of record numbers and column related information, because we want to make sure that no other thread is already modifying the data while the "nth" is still reading the data from the file.

Also, if I understand threading correctly, when a thread tries to access a object that is already locked by another thread, it is blocked and does NOT use any CPU cycles. So, I don't think I am violating this rule on the instructions.html -

"Any attempt to lock a resource that is already locked should cause the current thread to give up the CPU, consuming no CPU cycles until the desired resource becomes available."

But, please do let me know if you think otherwise.

I chose to use private static variables just like the one mentioned in Andrew's SCJD book. I guess the other way to do it is make the class that accesses the database file a singleton.

Thanks
Ravi
Nitesh Kant
Bartender

Joined: Feb 25, 2007
Posts: 1638



Also, if I understand threading correctly, when a thread tries to access a object that is already locked by another thread, it is blocked and does NOT use any CPU cycles.

I think you meant that when a thread tries to acquire a lock on an object that is already locked by another thread, it is blocked and does NOT use any CPU cycles. If that is what you meant, it is correct. Access of the object will go through even if some thread has a lock on that object.
So, I don't think I am violating this rule on the instructions.html -

No, you are not.

I guess the other way to do it is make the class that accesses the database file a singleton.


That is absolutely correct, but in that case you should take care that all clients of DBAccess are loaded by the same classloader as your DBAccess class or atleast your DBAccess class is loaded by only one classloader.
Conceptually, if any class does not have any instance level fields, then it does not make sense to instantiate it, i.e., it should have all methods as static. So, you can decide based on your usage.
 
wood burning stoves
 
subject: Question about locking inside the constructor of file accessor