This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Drawbacks of wait Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Drawbacks of wait" Watch "Drawbacks of wait" New topic
Author

Drawbacks of wait

Anton Kuzmin
Greenhorn

Joined: Feb 22, 2012
Posts: 19

Wait, then someone can lock the record for very long time and other clients will be waiting for very long time? And if yes, will they be able to cancel waiting technically? And what happens when client locks and crashes leaving record permanently locked?
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5147
    
  12

It all depends on the approach (thick/thin client) you take. In a thin client approach it's impossible to hold a lock forever, because the locking happens on the server. In a thick/fat client approach it's something that certainly could happen. So you should make a well-thought decision about that part of the application. You should always make sure that the period a record is locked, is as short as possible. If you already lock the record when the user clicks a record to book (and a dialog to enter customer id is shown) you'll risk indeed to lock a record for a very long time (certainly if CSR goes out for a coffee or lunch break) or even forever if the application crashes. Better would be to just start the whole updating process (including locking) when you have all information needed (so when CSR confirms the booking and has entered the customer id)

Hope it helps!

ps. don't wake up zombie threads. Just start a new thread and ask your question there.


SCJA, SCJP (1.4 | 5.0 | 6.0), SCJD
http://www.javaroe.be/
Anton Kuzmin
Greenhorn

Joined: Feb 22, 2012
Posts: 19

Better would be to just start the whole updating process (including locking) when you have all information needed (so when CSR confirms the booking and has entered the customer id)


Since the rooms are open for booking 24 hours, the best offers will be hunted the most and that could create situation when clients can get angry with too many "this room has been booked by another person" messages. Maybe old system had this problem Unfortunately, instructions don't mention it.
Anayonkar Shivalkar
Bartender

Joined: Dec 08, 2010
Posts: 1502
    
    5

Hi Anton Kuzmin,

Unless it's breaking any 'must' requirement(s), in my opinion, thin client is the best approach. The reasons being:

1) Locking takes place at server side. Client simply makes a request to server. Server locks the record, makes the changes and unlocks it.
2) Once the request is sent, it doesn't matter if client is crashed. The operation would be performed in a thread-safe manner (i.e. room would be booked as long as no other request for same room is processed).
3) Since server acquires the locks, its far easier to guarantee thread safety. Once a thread obtains a lock on the room, no other thread can obtain a lock (as long as that thread has the lock).
4) With this lock-update-unlock approach, you also minimize the risk of deadlock. No thread locks two records simultaneously, and no record can be locked by two threads simultaneously, so, no deadlock

The only considerable disadvantage is - CSR does actual operation after filling all the information - at which point, it is very much possible that another CSR is locked that room. For this thing, I provided a refresh button - which will simply refresh the status of records.

Anton Kuzmin wrote:clients can get angry with too many "this room has been booked by another person" messages

Well, keeping client happy is not a 'must' requirement(but data integrity is), so I guess its fine if client gets angry

I hope this helps.


Regards,
Anayonkar Shivalkar (SCJP, SCWCD, OCMJD, OCEEJBD)
 
jQuery in Action, 2nd edition
 
subject: Drawbacks of wait
 
Similar Threads
How to improve performance of Swing application
Passed SCJD with 359/400
locking and shutdown mechanism
any good study guide for SCDJWS?
NX: my idea about lock and unlock