Forums Register Login

Locking and Service Interface

+Pie Number of slices to send: Send
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!

+Pie Number of slices to send: Send
I don't like this approach, because a record can be locked for ever (user selects a record and then leaves for lunch or maybe even a 3-week holiday). And you should always try to keep the time a record is locked to an absolute minimum.

Because you can only search and book for contractors, how can a contractor go from 10 employees to just 5? I prefer to lock/update/unlock the record when user confirms the booking (or unbooking).
+Pie Number of slices to send: Send
Thanks for your response. What you've said is exactly the issue I was concerned with which made me question the approach.

I have changed it to lock in the service and the GUI (Presentation layer) now knows nothing about locking. It makes it cleaner too as I'm not having to pass the cookie around.

I think I was over thinking it a bit and thinking that the data could be changed via another program (Assumed this as how else would you add/delete contractors). I read the requirements again and it does state that "You may assume that at any moment, at most one program is accessing the database file". i.e. just the GUI.

My book method on the service now does Lock record > read record > if booked already throw exception (Which is handled by GUI) > update > unlock. This will maintain the data integrity.

I have stated in the choices.txt file that you could potentially check for any changes in the record between the users initial read and booking but as it's not possible to change data with the GUI design and it's assumed this is the only way of accessing the data, it was not implemented.

Do you think that will fulfil the requirements ??, thanks.
+Pie Number of slices to send: Send
That's what I did too and I passed. So I would say 'Yes'
"How many licks ..." - I think all of this dog's research starts with these words. Tasty tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com


reply
reply
This thread has been viewed 923 times.
Similar Threads
RMI confusion
Another Problem
Share parts of my choice.txt with javaranchers
Will this locking mechanism be allowed?
RMI newby question - B&S
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 28, 2024 02:56:46.