Hello ranchers, I am thinking about the design and some things are not clear for me. I have no much experience with Java and design patterns, so I need your help. 1. I have seen that many people have implemented an adapter class to the Data class to have all methods defined in the Sun interface DB but throwing the IOException. Is this really necessary? I have a try catch block in the methods, is this not Ok? Why is important to have the exception in the throw clause for the methods? 2.For the local mode I don't need to care about locking, synchonization. So I think I have to create a DataLocal class implementing also the DB interface like the Data class or a adapter class. I wait for your response. Regards, Maria
Originally posted by Maria Lepschy: Hello ranchers, I am thinking about the design and some things are not clear for me. I have no much experience with Java and design patterns, so I need your help. 1. I have seen that many people have implemented an adapter class to the Data class to have all methods defined in the Sun interface DB but throwing the IOException. Is this really necessary? I have a try catch block in the methods, is this not Ok? Why is important to have the exception in the throw clause for the methods? 2.For the local mode I don't need to care about locking, synchonization. So I think I have to create a DataLocal class implementing also the DB interface like the Data class or a adapter class. I wait for your response. Regards, Maria
Hi Maria, for the second point, what if the CSR opens a couple of windows and work with them. Don't you want to do locking at that time? I'm not sure about it, but its a scenario to take into consideration right? For the first one, I too am not sure. Will wait for big guys to answer Thanks.
Hi Maria, for the second point, what if the CSR opens a couple of windows and work with them. Don't you want to do locking at that time? I'm not sure about it, but its a scenario to take into consideration right?
The specification says,
You may assume that at any moment, at most one program is accessing the database file.
1. I have seen that many people have implemented an adapter class to the Data class to have all methods defined in the Sun interface DB but throwing the IOException. Is this really necessary? I have a try catch block in the methods, is this not Ok? Why is important to have the exception in the throw clause for the methods?
If your network communications approach uses RMI you will need an interface whose methods throw RemoteException (or a superclass thereof). This is the reason people are interested in having a common interface (suitable for local or remote access) whose methods are declared to throw IOException (a superclass of RemoteException). RMI requires an interface (the remote interface) that extends both this common interface and the Remote inteface. The class implementing this remote interface extends UnicastRemoteObject which gives the class the ability to be accessed remotely via RMI. The remote method invocation compiler (rmic) is run against the class implementing the remote interface to produce a stub for that class. One of the things the rmic does is check that all the methods in the class implementing the remote interface are declared to throw RemoteException. This is because when RMI is involved it is always possible that there will be communications problems that may arise and these problems will trigger RemoteExceptions. RMI requires that the remote interface implementing class handle these RemoteExceptions and the rmic enforces this requirement. These interfaces and classes (including the stub class) are all needed to support an RMI solution.
2.For the local mode I don't need to care about locking, synchonization. So I think I have to create a DataLocal class implementing also the DB interface like the Data class or a adapter class.
While it's true that you don't need to care about locking and synchronization for local mode, you might find that the burdens of locking and synchronization are not too onerous for the local database situation, in which case Data itself can server as the DataLocal class.
Hi Frankie, I interpreted it in a different way. Thanks for clarifying. So now, we have to write two different data access classes one with full locking capability for server clients, and one for local db clients which access the db file normally, right? Or can we use the same data access class for both local and server clients? Thanks.
Hi George, Thank you very much. I have not implemented yet the remote case and I am happy now to know why I need an adapter. To second question: If I understand you correctly (my english is not the best) you wrote that it doesn't matter if I provide the locking functionality also for local database access? Maybe it is better to not implement too many classes if there are not really needed. Regards, Maria
If I understand you correctly (my english is not the best) you wrote that it doesn't matter if I provide the locking functionality also for local database access? Maybe it is better to not implement too many classes if there are not really needed.
I did not implement a separate class for local database access in my project. I used the Data class for local database access and an adapter class (adapting the remote interface to the common interface) for remote database access. Since there are no performance requirements I didn't feel the need to make the local database access as efficient as possible (which would involve stripping out all the unnecessary locking stuff). I just don't think the locking is that burdensome in the local database case. Consider that in the local database case you never have to wait for any locks. If you request a lock for a record, you get it immediately, since you are not competing with any other threads.
![[Logo]](/templates/default/mobile/images/mobile-moose.gif)
