• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

DBMain database interface & RemoteException

 
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I know this issue has been raised a number of times but I'm still having problems building a solution.

I have the Bodgitt & Scarper DBMain interface. I'm using a DabaseFactory class to create a local or RMI connection based on command line arguments. I would like a single interface class to be used for both local and remote.

As an example, there's a read method in DBMain

public String [] read(int recNo) throws RecordNotFoundException;

and I have implemented

public class RecordNotFoundException extends IOException

So in terms of an exception hierarchy I should have

RecordNotFoundException
IOException
RMIException

I've tried taking the exceptions, RecordNotFoundException & DuplicateKeyException thrown by each method in the DBMain interface and have them extend IOException. And I've extended the DBMain interface in a new DatabaseInterface to give some additional methods. My idea was that I could simply use DatabaseInterface and if in local mode throw an IOException in local mode, and RemoteException in RMI mode. I belive this is possible as I can also throw the same or a narrower exception. For exampe with the read Interface method which throws RecordNotFoundException.

But though the code compiles, when I run RMIC tool to generate stubs for remote mode I seem to get errors such as

error: suncertify.db.DBMain is not a valid remote interface: method java.lang.String read(int)[] must throw java.rmi.RemoteException


thanks
Tim
 
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Tim

Personally I wouldn't make RecordNotFoundException & DuplicateKeyException subclasses of IOException IMO I feel that this is a bad design choice, is a RecordNotFoundException & DuplicateKeyException really an IOException. In my implementation I sub classed Exception directly.

My idea was that I could simply use DatabaseInterface and if in local mode throw an IOException in local mode, and RemoteException in RMI mode. I belive this is possible as I can also throw the same or a narrower exception. For exampe with the read Interface method which throws RecordNotFoundException.



For this to work I think you will need to have RecordNotFoundException extend RemoteException.

In my design I use a Connection Factory on the client which returns a Connection object. I give this object to my GUI Controller which then uses it to make data related calls for the GUI. I have two classes that implement the Connection interface, LocalConnection and RemoteConnection. My Connection interface contains all the methods the controller will need to serve the GUI's needs and each method signature throws a ConnectionException that way the client does not need to worry what type of exception was thrown whether it be a RemoteException or RecordNotFoundExcption.
 
tim parks
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
thanks for the reply. I'm interested in your design approach, as I too have a database factory using an interface that returns either a local or remote implementation.

Can you explain how your Connection Interface relates back to sun's DBMain interface and the Data.java file you are required to implement?

As an example, how is public String [] read(int recNo) throws RecordNotFoundException; dealt with in your LocalConnection and RemoteConnection

thanks for your thoughts
T.
 
Stephen Patrick
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Tim, my assignment is still in progress and I am not an expert and others will probably have far better solutions. This is what I have done so far - it may change. I opted for a thin client so I don't need to bother about a client locking a record and then crashing. I have a BookingDataMgr DAO that communicates with the data class it calls lock, unlock etc. The booking data mgr catches any exceptions thrown by the data class and throws a BookingException. On my client my LocalConnection class uses a
BookingDataMgr, if a problem occurs it catches a BookingException and throws a new ConnectionException. For remote mode my RemoteConnection class uses a RemoteBookingMgr object which is bound in the registry this object throws a remote exceptions as required by rmi and BookingExceptions as it simply acts as a proxy delegating calls onto a BookingDataMgr class. If the RemoteConnection object encounters a problem such as a RemoteException, BookingException it throws a new ConnectionException that takes the caught exception. So I have the following design


GUI (presentation)
controller throws ControllerException
ConnectionFactory(on client) - returns a LocalConnection object or RemoteConnection - throws ConnectionException
Server with Remote Booking Object object(Remote Mode only) throws RemoteException, Booking Exception
BookingDataMgr - throws BookingException
Data throws RecordNotFoundException etc

This works ok as my data class requires the use of cookies for locking. The only problem I have is I don't like the way I have a number of interfaces with similar method signatures that differ only in the Exception type they throw. I am not to sure if this is a good or a bad thing. IMO its good as each layer is encapsulated but to add a new bit of functionality will result in updating a couple of interfaces. I am currently looking at this, but am in a rush now to finish so may leave it.

Stephen
 
reply
    Bookmark Topic Watch Topic
  • New Topic