wood burning stoves 2.0*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes B&S: Exception handling in book method in adapter Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "B&S: Exception handling in book method in adapter" Watch "B&S: Exception handling in book method in adapter" New topic
Author

B&S: Exception handling in book method in adapter

Derek Canaan
Ranch Hand

Joined: Nov 05, 2003
Posts: 64
Hi,
What do you think of this idea:
1. The book method only throws one exception, BookingException (BX).
2. BookingException extends Exception
3. Unwrap any exceptions from Data and re-wrap them in BookingException
4. Send only BookingException to GUIController

This simplifies the BookContractor in GUI:

Comments, anyone?
thanks,
derek
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11404
    
  81

Hi Derek,
It does simplify your coding for now, but it makes the assumption that you will not be trying to do any recovery in the GUI level.
For example, if the book method failed because of a network error, then the user might want to retry (and after they have hit retry twice, they will get sick of it and talk to the administrator). But you no longer have that option - all errors are BookingExceptions, and all you can do is report on them.
You have to decide whether there is anything that you are wrapping in a BookingException that you might want to handle - if not, then you can ignore this comment.
Regards, Andrew


The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Derek Canaan
Ranch Hand

Joined: Nov 05, 2003
Posts: 64
Hi Andrew,
[Andrew]: but it makes the assumption that you will not be trying to do any recovery in the GUI level.

Some of the BookingException(msg) has msg that advises the user to try again (ie. click the book button again). Is such "recovery" good enough?
Or do you mean programmatic recovery?

If i do not have any programatic recovery, is having one Booking Exception for the adapter's book() method ok?
Could you also comment on the finally block on unlock. The goal is to release lock on the record in the event of an exception thrown during the lock/re-read/update/unlock process. What if unlock itself throws exception? The lock for that record will still be locked and never released. Is this right? If so, is there any way to unlock? What about programmatic recovery and try a few more times as shown below:


thanks in adv,
derek
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11404
    
  81

Hi Derek,
Originally posted by Derek Canaan:
If i do not have any programatic recovery, is having one Booking Exception for the adapter's book() method ok?

Should be fine.
Originally posted by Derek Canaan:
Could you also comment on the finally block on unlock. The goal is to release lock on the record in the event of an exception thrown during the lock/re-read/update/unlock process. What if unlock itself throws exception? The lock for that record will still be locked and never released. Is this right? If so, is there any way to unlock? What about programmatic recovery and try a few more times as shown below:

The problem with the auto retries is that if the record cannot be unlocked due to a network problem (or because the client application crashed) then this still won't help you.
Now you may not have to worry about client / network crash in order to meet the minimum requirements for this assignment. But if you do want to think about it to make a more robust solution, then you might want to look at the Unreferenced interface on the server site: that way your server will get notified if the client is no longer connected and can clean up any stale locks.
Regards, Andrew
Derek Canaan
Ranch Hand

Joined: Nov 05, 2003
Posts: 64
Hi Andrew,
The problem with the auto retries is that if the record cannot be unlocked due to a network problem (or because the client application crashed) then this still won't help you

Mine is a 3-tier design where the unlock is done at the server side. In the event of network problem or client crashed, the server side still tries to unlock the record. This is useful so that other remote clients can book that record. It would not help *only* if the design is 2-tier. Is this so or am i missing something?
.. look at the Unreferenced interface ... clean up any stale locks
This is scary - i'm almost done with the minimal requirements and this is actually the next thing i might consider.
Currently, i have only *one* RemoteAdapter bound to the rmiregister.
To clean-up stale locks, i need:
  • a factory to dish out one adapter to each remote client
  • a collection in each client to keep track of all records it has locked
  • RemoteAdapter implements Unreference
  • codes in unreferenced method to iterate over collection and call unlock

  • Is this right? Have i left out anything? If my design is 3-tier and if my analysis above is correct, would it make all these codes unnecessary?
    rgds,
    Derek
    Andrew Monkhouse
    author and jackaroo
    Marshal Commander

    Joined: Mar 28, 2003
    Posts: 11404
        
      81

    Hi Derek,
    Sigh. I keep assuming that people are developing fat clients. Then all my comments are blown out of the water. :roll:
    You are right - since you are developing a thin client solution, then you do not need to worry about cleaning up stale locks.
    Regards, Andrew
     
     
    subject: B&S: Exception handling in book method in adapter
     
    Similar Threads
    forced to lock and then read
    NX: URLyBird 1.1.3
    RMI Design : Following Max's Book
    Locking & Exceptions (B&S)
    All of URLy Bird 1.1.3 about Junit test