Win a copy of The Java Performance Companion this week in the Performance forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

which functions are actually used by the client?

 
Jonathan Elkharrat
Ranch Hand
Posts: 170
Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

as i understand from the specifications, the client can only book a room.
the functions to add, delete and create rooms are never used.
(there's really only 2 buttons in the GUI? "search" and "book"?)

moreover, there's not any requirement to have an "unbook" option.
(that lead to something funny: when a thread is locked waiting for a record
to be free it's wasting its time. the only time locking occur is for booking a
record and no matter what happens, the record will be already booked when
the thread resume...)

N.B.
there are no difference between standalone and client mode according to
the specifications...
 
Roel De Nijs
Sheriff
Posts: 10222
129
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You are correct
 
Sean Keane
Ranch Hand
Posts: 582
Chrome Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jonathan Elkharrat wrote:
moreover, there's not any requirement to have an "unbook" option.
(that lead to something funny: when a thread is locked waiting for a record
to be free it's wasting its time.


Hi Jonathan, just wondering what you mean by the thread is wasting its time when waiting on a record to become free?
 
Jonathan Elkharrat
Ranch Hand
Posts: 170
Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
i meant you could* already return with a "recordNotAvailable" or something like that,
because the only operation that lock the DAO is booking and since your thread is
locked because another thread is using that record, you already know it'll book it.

*of course you wouldn't do that because the specifications explicitly said to use the
waiting mechanism. if it was in real life that would be a waste of time...


another way to remove the need of lock/unlock (but NOT approved by the spec, of course) would
be to synchronize all writing method in the DAO class.
 
Roberto Perillo
Bartender
Posts: 2271
3
Eclipse IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jonathan Elkharrat wrote:i meant you could* already return with a "recordNotAvailable" or something like that,
because the only operation that lock the DAO is booking and since your thread is
locked because another thread is using that record, you already know it'll book it.


Interesting thought. On one hand, yes, you are correct. On the other hand, despite of instructions or anything else, the lock method would be doing more then it should. Also, let's say that, for some reason, after 2 months the project was delivered, the read method also required the lock method to be used. This would mean that the record would be still available even after it was locked. This would mean that you would have to change the find method (this would be a normal change) and also the lock method to not throw a RecordNotFoundException if the record to be read is locked (this wouldn't be necessary if the method had been correctly coded). So, despite of instructions or anything else, this wouldn't be a good thing simply because the lock method would be doing more than it should.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic