Hi,
I'm 90% done on the B&S project and just doing some refactoring and documentation. There is one particular area that's got me concerned and I'd really really appreciate some opinions. I have read other threads on this but still sitting at work on a Sunday going round in circles!
I have implemented locking as:
1. User searches for records and displayed in JTable
2. User selects a record. At this point I call a "reserveContractor" method on my service which locks the record, rereads and returns the contractor details.
3. User now has a JDialog with contractor details and can book, unbook or close.
4. Upon clicking book or unbook, I call unbook/bookContractor on the service which updates the record. The JDialog is update and remains open.
5. When done the user clicks close which calls "releaseContractor" on my service which unlocks the record.
This works fine except for when a record is locked. The second clients GUI hangs during step 2 waiting for the lock. I have documented in my Choices.txt that the GUI waits because of the consumes no CPU "must" requirement. I have also made the point that I wanted to lock the record before displaying it to the user so the record displayed is exactly what they book. i.e. you don't want to display a contractor with 10 employees. Click book but between displaying and booking the record is changes and you actually book a contractor with 5 employees. To me this completely destroys the integrity of the application.
I have considered removing the "reserverContractor" and "releaseContractor" and lock during the unbookContract/bookContract method in the service (i.e. lock/update/unlock). With this approach I could reload the record and compare incase it's changed, i.e. (lock > reread > compare (If changed throw a serviceException) if same / update / unlock).
I've got about a week to finish this assignment off and really not sure if my implementation will cause a failure. In reality I'd display a "record locked" error in the gui but this doesn't meet the consumes no cpu requirment.
Help!!!.... thanks!
I'm 90% done on the B&S project and just doing some refactoring and documentation. There is one particular area that's got me concerned and I'd really really appreciate some opinions. I have read other threads on this but still sitting at work on a Sunday going round in circles!
I have implemented locking as:
1. User searches for records and displayed in JTable
2. User selects a record. At this point I call a "reserveContractor" method on my service which locks the record, rereads and returns the contractor details.
3. User now has a JDialog with contractor details and can book, unbook or close.
4. Upon clicking book or unbook, I call unbook/bookContractor on the service which updates the record. The JDialog is update and remains open.
5. When done the user clicks close which calls "releaseContractor" on my service which unlocks the record.
This works fine except for when a record is locked. The second clients GUI hangs during step 2 waiting for the lock. I have documented in my Choices.txt that the GUI waits because of the consumes no CPU "must" requirement. I have also made the point that I wanted to lock the record before displaying it to the user so the record displayed is exactly what they book. i.e. you don't want to display a contractor with 10 employees. Click book but between displaying and booking the record is changes and you actually book a contractor with 5 employees. To me this completely destroys the integrity of the application.
I have considered removing the "reserverContractor" and "releaseContractor" and lock during the unbookContract/bookContract method in the service (i.e. lock/update/unlock). With this approach I could reload the record and compare incase it's changed, i.e. (lock > reread > compare (If changed throw a serviceException) if same / update / unlock).
I've got about a week to finish this assignment off and really not sure if my implementation will cause a failure. In reality I'd display a "record locked" error in the gui but this doesn't meet the consumes no cpu requirment.
Help!!!.... thanks!