Bob Reeves

Hi Niko:

I would add one other suggestion to Tom's list: Look for the simplist approach to each design issue, as the grader can be harsh for undue complexity.

Hi Vijay:

Look at the RMI registry. You must start the RMI registry at the server, and populate it with a Remote object. The client can then access the Registry and retrieve a stub to call.

I think that answers your question.

Hi Ray:
I think there's a difference between an "empty database" and an "empty file". I did the URLyBird assignment, and this database defines file header and file schema information. Without the header and schema information, you don't have a valid URLyBird database (i.e., the "empty file" case). However, it is valid to have an URLyBird database that contains zero records (i.e., "empty database").
My 2 cents is that if the database lacks the header and/or schema, then shutdown the application because the database is corrupt. These fields are required to actually use the database. (Now if you want your server to support a "create database" operation, that's different.)
Tx

Hi All:
My assignment was the URLyBird application, and I can relate how my submission was scored. I interpreted

"to search the data for all records, or for records where the name and/or location fields exactly match values specified by the user"
and "the search mechanism should be flexible..."

to mean two two specific search types and received Sun's OK:
1. Specify no criteria and get the "all records search".
2. Specify both name & location and get the "AND" search, or
search just name or location (i.e., other field is blank in query) and get
the "OR" case.
For the "flexible" search, I just provided an implementation that didn't prohibit using all fields in the FindByCriteria method. My implementation used nulls for "TBD" fields, but the comparison took place on all fields.
I also provided an "Exact" search where only records that matched identically were returned; i.e., fred does not match freddy.
The important thing, I think, is to fully document your interpretation.
Tx

Hi Davidd:
Perhaps the best approach is to ask yourself what your purpose is in completing the SCJD. If it's to pass the test and get certified: stop at what's specifically required. Do any more and you have schedule, design clutter, testing, documentation, and reliability impacts. If your purpose is to pass, I'd use the fields of the assignment as specified, and search only the fields required.
If you're interested in building the world's greatest GUI: then you need to explore the rules that make a good GUI. There's a vast library on this topic, and it seems two different people have three different opinions.
To GUI or not to GUI, that is the question ...
Tx

Hi Vlad:
My take on exception design is that it depends on how you want the client to handle them. I decided that I wanted the client to handle local/remote calls identically, thus I chained all server-side exceptions in the RemoteException.
My server itself didn't implement the Remote interface, but was wrapped in what I called RemoteServer, which did. The RemoteException went only from RemoteServer to my ClientProxy, where it was unchained and thrown to the client. Note: If you do it this way, you must consider how you want the actual RMI exceptions handled.
Some might take exception to this approach ...
Tx

Hi Vlad:
OK, I understand your concern.
My server contains a database object that implements DBAccess. The server itself doesn't implement DBAccess (i.e., a Facade Pattern). What the server returns to the client proxy is a record model, not the String [] defined in DBAccess. Specifically, the server has a method:
RecordModel readRecord(long recNo).
I don't have findPrefix and findExact search methods. I just have the
findByCriteria

Hi Vlad:
You asked how I delivered prefix and exact search.
I used the database specification that says a null termination is used for fields that are shorter than full field width. Thats is, for prefix search, I just sent a plain string as the query. For exact search, I appended a null termination at the end of the string. The query engine inspected the search string to decide which type of search to perform.
Hope that helps!
Tx
PS: In thinking about my results, I'd advise you not to add anything extra not required by the specification. Otherwise, you don't get any plus, but you might get a deduction for "unnecessary" complexity.

Hi Svetlana:
Yes, it's always possible.
Deadlock is difficult to test since the threads have to line up closely. I used the concept of "ordered resource acquire" to avoid deadlock, and this technique is known to work. That is, work if correctly implemented
My RMI tests did throw an exception: server connection refused. This occured when running 20 threads for 100 iterations. I read that other posts in SCJD found this problem, and some noted that it's a flaw in Sun's implementation of RMI. I can't think of any special exceptions that the lock subsystem could throw though, even runtime exceptions.
Tx

Hi All:
Thanks everyone for their well wishes! Let me provide some answers to the questions raised:
SB:

is that you had a LockManager class which had a collection for holding the locks and cookies?

The LockManager was a class that contained a Map holding my locks. I feel this is a solid approach and am appealing the score assigned.
Vlad:

1. DB Interface: have you extended DB interface to provide getSchema/getMetaData method for the client or did you hard coded length of field and so on on the client?
2. if 1. is Yes, have provided appropriate search methods(with exact search instead of prefix one) on the server or have done it client?
3. Have handled booking only in last 48 hours ... If yes on client or server and how?

1. Well, yes and no. I had a data model for the record that I passed back to the client. This model had methods to get the number of fields, their names, and their lengths.
2. I addressed this by documentation: I provided prefix and exact search methods -- and noted that no range or other search type was implemented.
3. My instructions said the records were to be used in 48 hours. It didn't require anything to be done about records older than 48 hours. I just ignored the 48 hour comment.
4. My client was single threaded. I documented this fact conspicuously since it greatly impact user response time. User response thime wasn't a requirement for my assignment.
Hope this information helps!
Tx

Hi All:
Thanks to the great community at JavaRanch for making the Developer assignment fun! Special thanks to Max for the interesting and thoughtful discussions -- and the helpful softcover! For those who are interested, my results for the uRLyBird assignment were:

The maximum possible score is 400; the minimum to pass is 320. General Considerations (maximum = 100): 98 Documentation (maximum = 70): 69 O-O Design (maximum = 30): 30 GUI (maximum = 40): 40 Locking (maximum = 80): 22 Data store (maximum = 40): 40 Network server (maximum = 40): 40
I offer these comments on design issues that have been discussed in this group:
1. Remote Object: My design had a single RMI remote object.
2. Datbase access: My design had a single RandomAccessFile/FileChannel that was shared by all threads and persisted for the life of the application.
3. Server Shutdown: I ignored the issue, but documented.
4. Logging: I used 1.4 logging.
5. MVC: I used an MVC architecture that avoided listeners.
What did I screw up with locking? Not sure. I used a lock manager collection and a specialized lock with acquire/release and timeout. However, I used a cookie scheme that permitted cookie sharing for multiple record operations; i.e., I permitted multiple record delete. I also permitted non-unique cookies. Furthermore, I synchronized all record read/write operations for data consistency. One of those choices probably did me in. Those who have read my previous posts probably can guess that I still think my design decisions were correct. Oh well ...
Thanks Everyone,
The latest SCJD

Hi Jmannu:
No, I don't think many -- if any -- developers are updating other users when a record is edited.
PS: If you have concerns, be sure to document them in your choices/design document.
Tx

Hi Jmannu:
If you update the four other users when one edits a record, then you're doing "live update". This feature is far beyond what I think the assignment requires.
Live update is appropriate in software that you can charge money for since it is much more complex!
Tx

Hi Max:
This responds to your comment:

But, the problem with Vlad point is that the compiler would have to examine your code, and know that you're only doing 3 bytes. Since it can't reasonably be expected to do this, then it has adhere to the specification. That doesn't mean that all methods always do so, but it's important to be clear that the method can't pick and choose when to adhere to spec and when not to.

The motivation for by post was a decompile of FileChannelImpl, which is the type of the obect returned from RandomAccessFile's getChannel.
The decomile of FileChannelImpl shows no embedded JVM Monitor enter/JVM Monitor exit calls in any of the write methods. But all the position methods have them. Now FileChannelImpl calls IOUtil and FileDispatcher. Again neither of these contain Monitor calls in their write methods.
So, I think you can see why I conclude that the block on write must be in the native code. I'd also opinion that native code protects itself on block (ie. so that its file on disk information remains valid), not the user. Thus my conclusion.
Notice there is no customization of the compiled code for short buffers. Of course, the compiler couldn't do that! I think the native code looks at the buffer length, and branches according to file length. (Actually, the only time it must block is if the truncate method is called after the write. I'm guessing truncate isn't called frequently, so it might make sense to optimize this way.)
Tx

Hi Max:
This responds to your comment:

But, the problem with Vlad point is that the compiler would have to examine your code, and know that you're only doing 3 bytes. Since it can't reasonably be expected to do this, then it has adhere to the specification. That doesn't mean that all methods always do so, but it's important to be clear that the method can't pick and choose when to adhere to spec and when not to.

The motivation for by post was a decompile of FileChannelImpl, which is the type of the obect returned from RandomAccessFile's getChannel.
The decomile of FileChannelImpl shows no embedded JVM Monitor enter/JVM Monitor exit calls in any of the write methods. But all the position methods have them. Now FileChannelImpl calls IOUtil and FileDispatcher. Again neither of these contain Monitor calls in their write methods.
So, I think you can see why I conclude that the block on write must be in the native code. I'd also opinion that native code protects itself on block (ie. so that its file on disk information remains valid), not the user. Thus my conclusion.
Notice there is no customization of the compiled code for short buffers. Of course, the compiler couldn't do that! I think the native code looks at the buffer length, and branches according to file length. (Actually, the only time it must block is if the truncate method is called after the write. I'm guessing truncate isn't called frequently, so it might make sense to optimize this way.)
Tx