Forums Register Login

Question about notifyAll() and wait()

+Pie Number of slices to send: Send
This is more of a design question actually...let's say that if a user selects a record in the JTable, and selects the Book Selected Record button, it will display the Book Record JPanel. Once the user enters this particular screen, I want the record to be locked. And then upon successful update/booking of the record, I want the record to be unlocked. Now if another user attempts to enter the Book Record screen while another user is already on the screen, I, of course, want the application to wait until the record has been successfully updated by the first user before the second user can enter the Book Record screen.
Now, my question is, how can I do this so that when the first user is done, the notifyAll() call will notify the other user who is waiting? I'm not entirely sure how I can set this up design-wise.
For example, if the user hits the Book Selected button, I call a method on the server-side that checks if the record selected is locked, and if not, it locks it then returns true. Now, if it is already locked, I call wait(). However, my particular problem then is how do I use notifyAll() once the update is done since the update is done in a totally different method on the server? Can I do something with my server class to be able to use the wait() and notifyAll() methods in different methods, but still affect the same thread?
+Pie Number of slices to send: Send
A little further clarification. The reason I'm having the above mentioned problem is that between the lock and eventually the unlocking of the record, there are client actions such as typing in the customer number and the clicking the Book Record button. Therefore, I can't handle all those on the server-side as they are strictly client-side actions. So upon selecting a record, and clicking the Book Selected Record (which brings up the Book Record screen), the server locks the record by having the client call the prepareUpdateRecord() method on the server(for example). Then upon a successful return from that method, the client will display the screen and the user can type into the fields and click the Book Record button, which then calls the update() method on the server, which will unlock the record when the update is done. Now, the question is how do I make notifyAll() alert the prepareUpdateRecord() method's wait() call that it doesn't have to wait anymore?

The reason I want to lock the record BEFORE the user can even get to the Book Record screen is that I want to avoid having two users updating the same record at the same time. It would be easy enough for me to just lock and unlock the record right in the update() method, but that wouldn't prevent the second user from at least seeing the changes the first user made to the record. So if anyone actually has a better solution to this dilemma...help would be appreciated!
[ January 08, 2005: Message edited by: Eric Chang ]
+Pie Number of slices to send: Send
After racking my brain about this...might I be able to have a separate class act as the monitor? And there is just one method to call that handles the notifyAll() and wait() calls? If this is a possible solution, then I feel pretty stupid for not seeing it earlier. What do you guys think?
+Pie Number of slices to send: Send
This is not really an answer to your problem, but more of a comment regarding your design.

Once the user enters this particular screen, I want the record to be locked. And then upon successful update/booking of the record, I want the record to be unlocked. Now if another user attempts to enter the Book Record screen while another user is already on the screen, I, of course, want the application to wait until the record has been successfully updated by the first user before the second user can enter the Book Record screen.

It seems to me that you have a huge potential for unreasonable freezes because of the amount of operations the actual user (person) has to do while the record is locked.

For instance, user 1 selects Record #1 and then hits the Book Selected Record button. Now the record is locked, and he enters the next screen. Now some type of human delay happens before he actually books the record, i.e. he forgets the customer ID number, gets a phone call, has to use the bathroom, etc. Meanwhile, user 2 tries to book the same record, and his or her application just appears to freeze up while they wait the 5 minutes or so before the lock is released and they can move on.

As a general rule of thumb, I try to limit the amount of operations that occur inside a synchronized block to a minimum, and if possible, I never put in code that waits for user input. I only lock the record immediately before an update (or delete) and I unlock it immediately afterwards.

Why not wait to lock the record until the user hits the Book Record button to lock the record, and then perform a check to make sure it has not been booked in the meantime? Just my thoughts...
+Pie Number of slices to send: Send
Hi Eric,

I agree with Paul's comments - your design could be frustrating for the end user who is staring at an unresponsive screen.

I think you have already found your solution though. If both clients are using the same object on the server, then your issues should be resolved.

Regards, Andrew
+Pie Number of slices to send: Send
Thanks for the comments Paul and Andrew. Here's my question though...if I was coding a real life application, I WOULD lock the record before entering some sort of Update screen...but I would most likely not allow the user to just sit there and stare at the screen, but rather display a message and allow the user to continue on their way, but NOT to allow them to update the locked record.
However, in this assignment, the lock method has been specified to wait() until the lock is free.
So I essentially have two choices: one is to go my merry way and continue coding what I "think" is best which is to lock the record before entering the Update screen.
The other choice is to lock right before doing the actual write when updating, but if I do that, then how do I do a "check" on if another update has occured before the actual update occurs like Paul said, and if another update HAS occurred, should I do something special about that?
+Pie Number of slices to send: Send
 

Originally posted by Eric Chang:
The other choice is to lock right before doing the actual write when updating, but if I do that, then how do I do a "check" on if another update has occured before the actual update occurs like Paul said, and if another update HAS occurred, should I do something special about that?



Hi Eric,

What my client does, is as follows:
- (user hits book button)
- lock the record
- read the record
- if the record is already booked, unlock (and inform user)
- else update and unlock

IMHO the read action in this scenario is the only reason why we need a lock and unlock in the first place. Otherwise the lock/unlock could have been integrated into the update method.

Frans.
So it takes a day for light to pass through this glass? So this was yesterday's tiny ad?
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com


reply
reply
This thread has been viewed 924 times.
Similar Threads
NX: Using SwingUtilties.InvokeAndWait method in GUI
URLyBird locking mechanism
NX: cacheless design to keep things simple?
Yes! Passed! 388/400
SCJD - 370 out of 400
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 28, 2024 11:30:13.