kerry shih

Couple of comments:
Remember that for local usage, you have to completely bypass RMI. UnicastRemoteObject's immediately export upon construction.
I think the general idea is to have only 1 Data instance. If you serve one to every client then your are initializing the whole service on each request. Plus it precludes you from having a centralized management for record locking, id tracking etc.
RemoteObjects and decendants of remote objects are threaded servers once exported. In other words the threading work is done for you. To try it, simply export a server and have multiple remote clients connect.
Hope this helps,
Kerry

After developing the whole project on Win 2K I was happy with the results. I threw it on Solaris and my client (in remote mode) could not connect, throwing access violation exception. I did not assign -Djava.security.policy=any.policy in the bootup on Windows and it still worked! Note that I still install an RMISecurityManager on the client. Its possible that on Windows the property is not necessary for localhost although that's speculation. Any ideas? Either way, make sure that you guys run it on unix before you upload!
Kerry

The way I handled it, in remote mode:
If the server cannot load the file, register in the registry or generally cannot initialize to the point of usefullness then it dies gracefully (much like weblogic!).
The mandatory server side exceptions are all that need be worried about. We don't need to make it any more complex. However, I wrap all server exceptions into one of two kind. DatabaseException and RemoteException. In other words, if the criteriaFind arguments are bad they will see a DatabaseException, if they cannot connect they will see a RemoteException etc. That way they don't capture any more than two exceptions on the client. I think your concern is whether you are missing some concept. I think if you follow basic exception handling and can explain your strategy then you will be fine. In other words if you choose to wrap everything on the server side and throw only RemoteExceptions so be it, just write it in design.txt.
Hope this helps,
Kerry

My take on this is that the client side application should know very little about the transport layer. In other words they should choose whether to connect locally or remotely but should not "see" any RMI initialization etc. The DataClient should protect them from such intracacies. Other wise the Data interface is just a bunch of delegation.

artima.com, jguru.com, theserverside.com as well as books esign Patterns, Design Patterns in Java.
The books are nice, each chapter holds many patterns under one category ie (Object Construction patterns, Designing with Aggregation vs Inheritence), and each pattern has source code and explanations.

There is no problem in simplicity. However despite all the normal advantages that patterns give you such as extensibility and maintainability, I find that patterns help modulate code into incredibly logical blocks. If you find that there is a lot of code in any given class then you can expect to have problems with maintanence and reuse. While many people preach these benefits I find from a practical point of view that I spend far less time making changes and feel much more confident regarding the readability of the code. My old style of programming used somewhat cheaper solutions and I would always get frustrated when I had to come back to the code later.
On a technical note. If you have different interfaces for communicating remotely versus locally then your client code is going to have to "if" around whether they want to communicate over the wire or not. For instance:
if (useRemote)
deleteRemote();
else
delete();
A general principal of coding is to keep away from tying your different tiers code to each other. Now if the basic signature of a method changes you have to change it twice in the data class and twice in the client.
Hope this helps
Kerry

It involves three components. Writing/completing a database server. Providing a networking protocal for interacting with
the db in a thread-safe remote way and lastly a GUI client interface for playing with the records. The amount of actual requirements are few and for the most part the means are more important than the ends.
There is a ton of resources in the forum alone so I won't list them. If you want to get started make sure you know a handfull of design patterns, brush up on how RMI and Swing works then download the assignment and give it a shot.
Kerry

I agree completely about your comment regarding trying to fit a solution into a pattern.
A lot of people in this test are overkilling the project (as am I), but do our defense it is a rare opportunity to use/try new patterns.
For all who are new to patterns, a lot of the time a pattern is just a logical relationship that occurs all the time that you never new was a pattern. Example: Delegation is hardly a pattern its just a fundamental way that a "has-a" relationship works. So brush over the IDEAS behind what they try to accomplish and then do your best to see if one can help.

I found a good way to learn how to comment is by looking at Sun's jdk code. If you have the source or find it on the net. Their code is a pretty good example of elaborate documentation.

I would shoot to have the server side impl of the lock use Java's thread locking mechanism. That way your method call won't return until the server impl gets wind of the lock acquisition.
Kerry

I like your solution. I have a question though. If a remote client dies wouldn't your server side impl not necessarily be notified? I was thinking about a timeout mechanism that would insure that records wouldn't lock forever.
Either way this is not a requirement so Ill probably let it go. There's better ways of scoring points!
Kerry

Question. If you boot up using the local protocal do you guys require the RMI Registry to be started or do you "switch" it out for local vs remote usage. I have a DataClient that uses a Singleton data service that on first initialization binds an interface into the registry. I didn't want to have the registration based on whether the data client wanted to be local or remote. Any thoughts?

I have experienced the same problem with Weblogic and their t3 protocal. It really sounds like a Windows dns timeout and the "default" ip address is used (which is why it probably still works). If you haven't tried already, use your full ip address ie (192.168.etc) or machine name in your URL, and / or try putting a static reference in your hosts file and try using that name.
Kerry

I ran into the same problem. I decided that it was justifyable to have the coupling as the app requires local and remote access. Assuming that this functionality must exist within the same build you would HAVE to have those classes in the client code. We have to remember that this project is not a lesson in RMI bootstrapping with a completely clean client.
Hope this helps

I would assume that this is not allowed as the test is designed to see our design ability. While choosing a third party solution is certainly a valid business decision I think it would stretch the goals of the certification.