This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Hi i am currently doing the URLyBird assignment, and something has me sorta stumped. I understand how to lock, but the real problem if anyone was making a locking system with Sun's specifications for the CPU to do nothing till it is unlocked, the user would want a cancel button.
Should i try and implement a cancel button to stop waiting but the only way i can think to do that currently is by the client creating a new connection and disconnecting the old one. The reason why i say this is cause currently in my code the server connection won't listen again till after the lock method has finished. and by disconnecting on my server will cause that connection to release any locks on any Records, but having a client disconnect and reconnect seems like a really bad way to have a program.
does any one have any ideas around this problem or should i just not have a cancel button but as you all know this means the client program will tend to hang while waiting for the lock record.
I don't think you need a Cancel button. The only reason the client should be doing a lot of waiting is in a deadlock scenario, which I would advise you to prevent. Yes, the client has to wait on the lock, but the lock should only be active when a record is being updated, and that will take such a short amount of time that ordinarily no one will notice.
In fact, if you add a Cancel button, I think you will have a tough time testing it because the record won't be locked long enough