File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

gui clients can lock same record

 
Dmitri Christo
Ranch Hand
Posts: 81
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello again,

As my final testing progresses, I stumbled upon a new frightening problem in my design. My setup: Bring up a terminal to start the server and then two new separate terminals to start 2 different gui clients in network mode. I noticed that both clients can easily lock the same record at the same time! (Severe design error!). Strange, since my locking design works perfectly when multiple non-gui clients try to lock the same record. I expected the second gui client to at least block when trying to perform a book/unbook action on the same record the first client was in the middle of booking.

After doing some searching on the forum I discovered this has to do mainly with two things: 1) The guis/client screens do not provide a real time view of the data - there is a debate on why it is not a good idea to constantly poll the server or refresh each client's screen continuously to capture other clients' actions. So basically there is no way for one client to be aware of what other clients are doing at one specific point in time. Which seems preferable actually. There is also some conversation about swing thread-safety and worker threads, which I think most people won't recommend for this assignment, (out of scope perhaps?)

..and 2) It seems that I have included my book/unbook functionality on the gui/client side, the gui controller specifically, which lets the lock/unlock functionalities to be handled by the client... But I am a bit confused here because the client gets a stub of the interface (since this is RMI), which means that the worker methods are actually called on the server side right?
So the locking rules should apply for the guis too? I have tried to read the thread should lock methods be callable by the client, but have to admit I am not sure how the other design (server locks the record for the gui) could be implemented.

..So, I guess I am wondering if this is a show stopper for my assignment and you would recommend I go back to the drawing board? Did you have to deal with a similar concern? Perhaps SUN expects this to be an inherent 'flaw' of many designs? I am sorry if my question is too complicated..

Any insight appreciated!
 
Sean Beecroft
Greenhorn
Posts: 26
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
go back to the drawing board. You are required to lock the record.
 
Dmitri Christo
Ranch Hand
Posts: 81
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
..problem actually solved. Thanks
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic