aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Locking - URLy Bird 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 "Locking - URLy Bird" Watch "Locking - URLy Bird" New topic
Author

Locking - URLy Bird

Michel Bertrand
Greenhorn

Joined: Jan 31, 2003
Posts: 26
Hi!

I failed in URLy Bird assignment due to the Locking mecanism approuch.

I have the following at my test result:

The maximum possible score is 400; the minimum to pass is 320. General Considerations (maximum = 100): 100 Documentation (maximum = 70): 70 O-O Design (maximum = 30): 30 GUI (maximum = 40): 38 Locking (maximum = 80): 0 Data store (maximum = 40): 40 Network server (maximum = 40): 40 Major point loss for record-locking mechanism, which is not according to spec. In the Data class, the lock() method is supposed to block when requested to lock a locked record. Your implementation returns immediately.


When trying to access a database locked record, my app returns directly
and it shows a message saying "Record locked ...". But looking at the
examiner comments, I would to block the request to lock the record unitl it becomes avaible. Am I right ? Should I use wait() and notify() in the lock method of the database class ?

Using it, I block the request, but the app window with is waiting for the lock release becomes blank. Is there any wait to avoid this behavior ?

Could anybody help me ?

Thanks in advance!
Michel.

[Andrew: changed code] [block to [quote] block]
[ January 07, 2005: Message edited by: Andrew Monkhouse ]
Dieskun Koper
Ranch Hand

Joined: Aug 15, 2004
Posts: 85
Hi Michel,

Too bad you failed. Other than the locking, your score is awesome!

The javadoc for the java.lang.Object.wait method uses similar wording as what the instructions say, so I think it is the best way.
There have been several discussions whether to use notify or notifyAll, you might want to search for them.

To prevent the GUI freezing up, we create worker threads to communicate with the DB. This way, the event-dispatching thread (the VM's thread that paints components) does not get blocked.
Once you get the results back from the DB you can update your GUI on the event-dispatching thread again.

You'd better read into this to understand what is going on.
You can find a lot in Sun's Swing tutorial. Search for "AWT event dispatching thread", "worker thread" and "SwingUtilities.invokeLater(...)".

Good luck,
Dies
Michel Bertrand
Greenhorn

Joined: Jan 31, 2003
Posts: 26
Hi!

Thanks for your answer !

I will look for the topics you listed.

Regards,
Michel.
Daniel Simpson
Ranch Hand

Joined: Sep 02, 2004
Posts: 181
Originally posted by Dieskun Koper:
Hi Michel,

Too bad you failed. Other than the locking, your score is awesome!

The javadoc for the java.lang.Object.wait method uses similar wording as what the instructions say, so I think it is the best way.
There have been several discussions whether to use notify or notifyAll, you might want to search for them.

To prevent the GUI freezing up, we create worker threads to communicate with the DB. This way, the event-dispatching thread (the VM's thread that paints components) does not get blocked.
Once you get the results back from the DB you can update your GUI on the event-dispatching thread again.

You'd better read into this to understand what is going on.
You can find a lot in Sun's Swing tutorial. Search for "AWT event dispatching thread", "worker thread" and "SwingUtilities.invokeLater(...)".

Good luck,
Dies


Hey Dies, your explanation helped me now understand why my GUI was freezing. Here was the post I made before on it. I haven't done networking yet, so I had sychronized methods for lock, unlock, and update. Because I was testing it in local mode, the event-dispatching thread was the one being blocked in the lock class, causing my table to freeze up. I realized that I didn't need locking for local mode as the spec says so I created an overloaded update method, to take care of that. So now I understand. Here's another question, how does locking work when a thread goes into a synchronized method, and then inside that method, that method calls another synchronized method? How does sychronization work with that?


SCJP 1.4<br />SCJD 1.4
peter wooster
Ranch Hand

Joined: Jun 13, 2004
Posts: 1033
Originally posted by Daniel Simpson:

Hey Dies, your explanation helped me now understand why my GUI was freezing. Here was the post I made before on it. I haven't done networking yet, so I had sychronized methods for lock, unlock, and update. Because I was testing it in local mode, the event-dispatching thread was the one being blocked in the lock class, causing my table to freeze up. I realized that I didn't need locking for local mode as the spec says so I created an overloaded update method, to take care of that. So now I understand. Here's another question, how does locking work when a thread goes into a synchronized method, and then inside that method, that method calls another synchronized method? How does sychronization work with that?


You can synchronize on the same object without problems, if you synchronize on a different object you must be very careful to always do the synch in the same order. If you do it in the opposite order anywhere there is a good likelyhood that a deadlock will occur.

P.S. Please put some line breaks in that code block so this thread will display properly.
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Locking - URLy Bird