File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Locking and Service Interface Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Locking and Service Interface" Watch "Locking and Service Interface" New topic
Author

Locking and Service Interface

Ian Lewis
Greenhorn

Joined: May 06, 2012
Posts: 2
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!

Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5139
    
  12

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).


SCJA, SCJP (1.4 | 5.0 | 6.0), SCJD
http://www.javaroe.be/
Ian Lewis
Greenhorn

Joined: May 06, 2012
Posts: 2
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.
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5139
    
  12

That's what I did too and I passed. So I would say 'Yes'
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Locking and Service Interface
 
Similar Threads
RMI confusion
Will this locking mechanism be allowed?
Share parts of my choice.txt with javaranchers
NX:Locking - one data instance or multiple
Locks callable by client: how to avoid client holds lock eternally?