Lara McCarver

Why would you use Random, then keep track of what has been used... this really sounds like a lot of work. Couldn't you have a static int in your LockManager class which incremented in the LockRecord() method, and handed back in a thread-safe way? (I didn't use locking cookies in my assignment, so I could be way off base here.)

Lara

I would recommend using Generics if you are using 1.5. Yes, it is a little more work(if you are currently not using Generics), but it is also a way of letting the compiler catch your bugs for you
[ March 02, 2006: Message edited by: Lara McCarver ]

An OR relationship is if you want all records that have a particular Hotel name, or else have a particular Client name. (Assuming these are the 2 fields you need to handle... for my B&S it was Contractor & Location). It's the union of the 2.

I don't think the lack of the OR relationship was what brought the points down. I think it is that it is annoying to have to enter an exact name, especially if you are a bad speller If I was going to enhance the UI, I would add an Exact Match check mark next to each text field. By default, it would be off, but users could turn it on. (That is to meet the requirements that we provide an Exact Match capability).

Or, you could provide a copy/paste capability within the table, so you could copy from a table cell into the text field. That didn't work on mine... well it sorta worked, except that the copy from the table cell returned data for the whole row, which is not exactly what you want to paste in.

Finally, I think I read about someone who got all the unique Names and Locations from the database and then allowed the user to pick from a combo box for these fields.

Lara

I interpreted this to mean that you need javadoc for each package, class and method. (The doc for the package and the class is just a few lines long for each.) You don't need to use the -private flag.

Lara

No, my search requirements did not require complex queries. I allowed the user to enter the 2 fields it specified. If both were entered, it was an "And" query, because I think that ordinary users are confused by "Or" queries, or even by having a choice (I think I mentioned that in my issues.txt). I think that it is awkward from a UI perspective to have to enter an exact name, but it did specifically require that. Maybe I should have made "Exact match" be a check-mark, that would have been more user-friendly and still met the requirements.

When you get points off in an area, they don't tell you why, so I am just guessing, same as you. Maybe I missed something basic that was in the requirements. Maybe they didn't like the fact that I allowed users to sort on any column they wanted to, but I didn't do anything to the column heading to visually indicate which field was sorted on. Maybe, maybe, maybe...

Lara

I think it's curious that everyone in the forum is always asking questions about locking design, whether caching is necessary, etc., but you rarely see questions about what is needed for full points in the GUI. I had a pretty simple GUI, for example just a simple text field to enter the search string into, although I did implement sorting in the table so I wasn't totally lazy. Anyway, I didn't get full points for the UI section (only 31/40), but whether that is because it was not so friendly to use, or if there were specific things they were looking for, I have no idea.

Lara

I don't think you need a Cancel button. The only reason the client should be doing a lot of waiting is in a deadlock scenario, which I would advise you to prevent. Yes, the client has to wait on the lock, but the lock should only be active when a record is being updated, and that will take such a short amount of time that ordinarily no one will notice.

In fact, if you add a Cancel button, I think you will have a tough time testing it because the record won't be locked long enough

Lara

Buy books.

One book should be Andrew Monkhouse's book on the SCJD exam, which I'm sure is a great overview (even though I haven't read it, but I read the previous SCJD book).

Also, for each area that the exam covers that you are not very comfortable with (you will figure that out by reading the SCJD exam book), you may need to buy a separate book on just that area. Like, if you haven't done much Swing programming, but a book on Swing. If you haven't even done any RMI programming, buy a book on that.

First, thanks for all the kind responses

Well let's see, the exam asks you questions about your program. The questions ask you what you did in your program, either in terms of the internal code or the UI, and then it will often ask why you made that choice and/or what alternatives you considered. It doesn't always have to be a deep reason, in my opinion. Like for one I said it would be easier that way (I did explain why) and for another I said that I couldn't figure out any alternatives. But if there is a serious alternative, you have to indicate it. So... before your exam, review your code and also use your app a couple of times if it has been a while since you wrote it. I have to say that I didn't answer all the questions 100% accurate... there was one place where I said I thought my program did X, but I did say I wasn't 100% sure, and then when I went back home and tested it, it turned out it didn't do that, and so I was really worried about that, but I did pass so... I guess you don't have to be perfect.

In terms of the deleted flag, I examined it using Hex mode in Textpad and it was 00 or FF I think, so I tested for that, and then I stored in my lock manager a state flag for every record in the database. The state flag not only had values like VALID and INVALID but also it had a value for CREATING I think. This was part of what I mentioned in my original post, I thought through a lot of possible scenarios including making sure that creating records could not collide with each other. For example, what if 2 users try to create a record at the same time. You have to be careful because if you let them both try to create record 51, there will be obvious problems. Creation can fail, in which case the state of the record gets flipped to INVALID.

I tried to avoid any deadlocks, but I used simple mechanisms, e.g. saying that only one client at a time can create a record. Also, saying that each client can only be modifying one record at a time. These are both pretty limiting, for deadlock in particular I know it's OK for a client to grab more than 1 record, as long as they do it in the right order. My goal was to avoid server problems caused by poorly written clients. I chose simple solutions because, in my opinion, writing your own database is a stupid business decision (unless that is the goal of the company, to be a database vendor). I think I might even have said this in my exam or in my issues document, as the justification for why I used simple and over-restrictive solutions at times. I said that I was planning on convincing the company to start using a real DB

A fourth possibility is to use a separate listener for each button or menu, but in places where code sharing is possible, have the listeners use a static method somewhere, or have the listeners call a common method in the parent object.

In my opinion, Java is more naturally structured to have separate listeners for each button and menu item. For example, in Core Java, they try to show how different buttons can share the same listener but there is no natural mechanism to differentiate the buttons. I think they end up using the string which is on the button, but if you ever want to internationalize your product, you will end up with different names for different buttons, so I don't like that solution.

I don't really think the code is harder to maintain with separate listeners for each button. It might be a little bigger, but that's not a real problem. What makes code hard to maintain is when you have the same code being used in three subtly different ways. Then changing that code to solve one problem can break the existing working solutions for the other cases.

Lara

The maximum possible score is 400; the minimum to pass is 320.

General Considerations (maximum = 100): 90
Documentation (maximum = 70): 69
O-O Design (maximum = 30): 30
GUI (maximum = 40): 31
Locking (maximum = 80): 80
Data store (maximum = 40): 40
Network server (maximum = 40): 40

Total (maximum = 400): 380


I wanted to thank everyone here. Especially... hmmm... the person who suggested to me that you should worry about dirty records (because the record on the server can change between when the client reads it and when the client makes an update to a record) -- that never occurred to me. And Andrew Monkhouse for keeping the forums alive and answering all kinds of questions with thought provoking answers.

One thing that really took a long time at the end was scrutinizing and fixing up all that java doc. My user documentation was really short, only 3 pages And my issues document turned into a design-explanation that was 8 pages long I think. I used standard mechanisms for locking, the kind everyone talks about. (None of the fancy classes from 1.5, though I used 1.5 because of some of the great new features, in particular you don't have to fuss with stubs.) But I did try to think through all the little corner cases, and I did create a bunch of junit tests to check for thread safety.

I ordered Andrew's book but in the end I submitted my assignment days before it arrived and I haven't even taken it out of the packaging I used the general adaptor approach recommended in the SCJD 1.4 book to handle the client/server/standalone requirements. The explanation was confusing, but I looked at the source code and how all the classes related to each other and figured it out. Also, in the SCJD 1.4 book they explain how to get the RMI server to register itself, I am not sure I could have figured it out otherwise, even though I read at least half of Java RMI.

I took the exam on Dec 15. I was worried because one or two things I didn't describe accurately... kind of embarrassing... I can't say what they were though because of the Vow of Secrecy I took But it was all OK. I got the certificate in the mail about a week ago. I was never mailed my score, but I sent Sun an e-mail and they said to log into
http://www.certmanager.net/sun_assignment/ to get my score, so that's what I did.

Thank you, thank you, thank you!

Lara

I interpreted "framework" to mean that you should have a good architecture/design. It seemed so vague to me. And without knowing what kind of enhancements are going to be requested in the future, it is hard to know whether future enhancements will disrupt your users or not. I turned in my exam, but I haven't gotten back a grade yet, so I can't tell you whether or not this was a good solution.

I just submitted my exam last night. There were a couple of diagrams I wanted to add, though nothing extensive, but the instructions were
pretty clear that it had to be a plain text file. I was surprised they
did not say that it would be OK to submit either plain text or HTML.
Anyway, I created ASCII art in the plain text file. Again, these were
just a couple of small diagrams so it was feasible but (of course)
painful.

I guess what Andrew is saying is that in your plain text file you could refer the reader to the diagrams you have. And these other documents
are not issue discussions so it's OK if they are not plain text.

Lara
[ December 13, 2005: Message edited by: Lara McCarver ]

I have completed the coding and documentation for my exam but I'm not sure what to do next. I looked at my "requirements" HTML file, and it did not say where to turn in the assignment. So far, I have only purcased CX-310-252A, which cost $250.00. Do I need to purchase CX-310-252B in order to upload the assignment to Sun? Or do I just need to know the right web-site?

Lara

I like the idea. 1 vote = yea. I think it fits naturally into the id of eventually having the user enter a userid/password. Though you can't change your DBMain interface, which may or may not want an id. Also, I am wondering how, in your implementation, the server knows that it is a new client that it needs to create a new ID for.

Lara