B Chen

More important than length is the content, you need to write enough to convince the accessor that you did the assignment. I wrote two or three paragraphs for three of my questions. And for one question I wrote only one sentence. I passed.

Originally posted by Thirumurugan Mylrajan:
I used one RAF per method call. But it has its own set of problems too..

I think many people prefer synchronization..

What are the benefits of using multiple RAFs? You would still have to synchronize. What happens if a write operation occurs in one RAF at the same time a read operation occurs in another RAF, affecting the same record?

Such failure scenarios are not in the scope of the assignment. I wouldn't worry about it.

The network server has nothing to do with business-logic. It just means your database needs to have the ability to be accessible over the network.
You can put the business-logic on either client-side or server-side. Each has its own pros and cons.

Don't worry. Just go over your choices.txt, and quickly review all the major classes in your app. Then get a good nights sleep.
Remember that goal is to convince the accessor that you wrote the app. You don't need to write a book for each question.

With some persistence, you could have found this
http://faq.javaranch.com/view?ScjdFaq

SCJD is more general application development.
Since you seem more interested in J2EE, then SCWCD, SCBCD, and SCEA might be more in line with your goals.

Except for embedded systems, I generally avoid having such limitations like "max number records" in my programs. For one thing, it complicates the code with addition checks for these self-imposed limits. Performance may be slightly better, but its not worth it. Computing power gets cheaper every year. It cost more for developers to do extra hand-coding to squeeze out every bit of performance possible.

I think that when most programmer see RecordNotFoundException, they assume it means that the record really is not in the database (and the database is still healthy). Most programmers would not think RecordNotFoundException would mean anything else, and programmatically follow the chain to determine the real root cause and handle it appropiately. Just imagine how that code would look like.
I like RuntimeException because you can handle any unexpected situation with one catch block (usually just log/display the error).
[ June 13, 2006: Message edited by: B Chen ]

Originally posted by Bob Nedwor:
May be some day I will get a shot at a position where I am actually doing some Java Programming. Passing the SCJD only helps.

It sure will. You should consider doing development.

Originally posted by Bob Nedwor:
Why do you ask?

I was just wondering, since it didn't sound like you were a career programmer or a recent CS grad, the two main group of people who may be motiviated enough to do SCJD.

Good luck with SCWCD. You should find it easier than SCJD.
[ June 13, 2006: Message edited by: B Chen ]

Congratz Bob. Pretty impressive. SCJD is hard even for many career developers.
If you don't mine me asking, what do you do that pays your bills?

Originally posted by Sham Delaney:
I keep all the data in a cache. And dont write to the DB after each update/delete. I wait and write out all the records at specified intervals.
The cached data is the db and it is current..i write to the db file as backup.

Should I be updating constantly to the DB file ?

Writing all records whether it changed or not kind of dampens the performance gains of using a cache. You could mark the records 'dirty' when changed and write only those records out when you flush the cache.

I also think using a cache is overkill for the assignment.

You could 'remember' the record number of the record you modified and select that row when you redisplay the records.

If the server changes it settings, the client GUI would then show the 'wrong' settings. When the user tries to connect, there will be some error, like "Connection Refused" on socket. Display the error in a dialog. The user then dismisses the dialog and enters the new settings in the client GUI, and tries to connect again.

hostname, port, and db filename are stored in the properties file after successful connection or opening of the db file. Next time the GUI starts (client and server), it populates the fields with values from the properties file.
[ June 08, 2006: Message edited by: B Chen ]

Mihai,
Does you requirement specify that the client needs to be able to switch to different servers while running, without restarting the client? I had no such requirement, so I simply provided a "Quit" function to terminate the client. Besides, if the user wants to switch servers (which I'd imagine would be rare if ever), they can easily restart the client.