File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes NX:  locking 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 "NX:  locking" Watch "NX:  locking" New topic
Author

NX: locking

Maria Lepschy
Ranch Hand

Joined: Jan 12, 2004
Posts: 78
Hi ranchers,
The first point is that I don't understand why we should implement explicitly locking. It is not so that synchronization avoids multiple access and the object is locked? Or the explicit locking is necessary to avoid deadlocks? Please clarify me.
I have no idea how I can test the locking functionality.Please give me some advices and usefull links to read about this.
Thanks,
Maria
Mehmet Atlihan
Greenhorn

Joined: Mar 03, 2004
Posts: 20
Hi Maria
The first point is that I don't understand why we should implement explicitly locking


When clients do a searching or booking ( may be create or delete for administrators) what you internally do is to operate on the database file you are given and display a search result or accomplish a booking by writing to database file. As the database is accessed concurrently ,you must preserve the database files integrity at all time during the execution of your application. At that point you should consider the following fact :
You must not allow two different clients to book the same room or the same seat at the same time otherwise it would be a disaster
So how would you implement this logical behaviour? Thats what locking mechanism is needed for. Before booking a room/seat your application first asks for a permission from the database via a lock() call over a specific record. That is the record which holds the information about the seat or room you are attempting to book. If the permission is granted then you keep going on. If any other client attempts to book the same room at that time, the application again asks for a permission from the database via a lock() call on the same record. But since the record is locked by some other client earlier, lock() call is denied for that client and he is put into a quee and starts to idle until the thread who owns the lock finishes and frees the record by invoking an unlock() call. This is simply accomplished by object.wait() and object.notifyAll() methods where in this instance Object denotes a data structure possibly a hash map which holds the locked records information.
It might be confusing for you if you are not familiar with Threads or writing multi threaded code. If none of these make sense to you then I would take any Java book or visit a java tutorial site and study Threads in detail.
Or the explicit locking is necessary to avoid deadlocks? Please clarify me

Answer is no. As a matter of fact your lock mechanism may cause a deadlock. So you should come up with a deadlock free locking implementation.
This has to do with Threads knowledge as well. So if you have problem with following this you really need to study Threads very well.


I have no idea how I can test the locking functionality.Please give me some advices and usefull links to read about this.


Well again Threads is your answer. What I did was to create sufficient amount of different Threads say 50, and log every threads actions.That way
I was able to keep track of my locking mechanism.You should try different inputs. For example you create say 10 Write Threads, that is booking a room/seat threads for the same record, and you monitor them during the application.
For usefull links , if you are confident with your basic Thread knowledge
this forum is an invaluable resource. Just do a search for a lock/unlock topic you will recieve hunderends of links. Other than that , Suns web site has a rich tutorial about other topics that you should be familiar with such as Swing,RMI.
Regards
Mehmet
Maria Lepschy
Ranch Hand

Joined: Jan 12, 2004
Posts: 78
Hi Mehmet,
Thank you very much for your long answer. I will now study threading more carefully.
Regards,
Maria
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: NX: locking
 
Similar Threads
URLyBird 1.3.1: passed (383/400)
NX: starting on the RMI side
B&S Booking and locking
1) no cpu cycles 2) book a selected record 3) the general user interface level
URLyBird: How to design network layer?