• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Drawbacks of wait

 
Anton Kuzmin
Greenhorn
Posts: 19
Eclipse IDE Java Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Sheriff
Posts: 10666
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Anton Kuzmin
Greenhorn
Posts: 19
Eclipse IDE Java Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1557
5
Eclipse IDE Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic