Paul Goh

How to view your SCJD results Linky

--
How would the following be interperted?

1. Your programs MUST not require use of command line arguements other than the single mode flag, which must be supported

2. Your programs MUST not require use of command line property specifications ----> i.e No parameters should be at the command line

3. All configuration must be done via GUI and must be persistent between runs of the programs ---> i.e Configuration the server such as hostname and port must done via GUI. Is this on the sever side? and stay alive throughout when the server is running.

4. The mode flag must either "server" indicating the server program must run, "alone", indicating standalone mode, or left out entirely, in which case the network client and GUI run -----> no ieda what this means
--

1. Other than the mode flag described in point 4, your program should not use any other command line argument.

2. Meaning you should not require the examiners to do this "java -jar <path_and_filename> -D... -D... <mode>".

3. Point 3 is optional, you can hard code it into your program, or you can use a properties file.

4. This means that "java -jar <path_and_filename> server" will start your database server, "java -jar <path_and_filename> alone" will start your standalone GUI client, and "java -jar <path_and_filename>" will start your network GUI client.

Can't be, I increment my long cookie by 1 everytime I need a lock cookie, so there can never be a repeated number, but still I get 44/80.

You should use the link:
https://www.certmanager.net/~sun_s/assignment.html

Then press the "Test History" Button. You will see the score immediately if it is available. There is also a "<< Details" button to tell you the breakdown of the score.

Good Luck!

Regards,
Paul

My personal opinion is that scjp is child's play compared to scjd. Although I passed scjd, I still cringe when I think about what I have to go through to get it.

I return the search result in an ArrayList for convenience, here is an example of a method on the server (The find() and read() methods are wrappers of the same method in the Data class, except that I do lock/unlock when necessary in methods like delete() and update().):
public ArrayList findHotel(String name, String location) throws RecordNotFoundException { int numberOfFields = hotelDB.getNumberOfFields(); String[] queryStringArray = new String[numberOfFields]; // Construct the query string array to contain only the name and location, leaving // other fields blank. for (int i = 0; i < numberOfFields; i++) { if (i == 0) { queryStringArray[i] = new String(name); } else if (i == 1) { queryStringArray[i] = new String(location); } else { queryStringArray[i] = new String(""); } } // Use the query string array to find the record numbers from the database. int[] recordNumberArray = find(queryStringArray); // Use the retrieved record numbers to read all the record fields from // the database and place it in an <code>ArrayList</code>. ArrayList tempArrayList = new ArrayList(); for (int i = 0; i < recordNumberArray.length; i++) { tempArrayList.add(hotelDB.read(recordNumberArray[i])); } return tempArrayList; }
[ October 07, 2004: Message edited by: Paul Goh ]

Hey Marlene, I think the same thread that obtained a lock is able to obtain the same lock again, no problems, however, based on my thin client design, this is also not an issue as the server determines how the record is locked, not the client, so the lock method will never be called twice by the same client (my GUI client is single threaded.).

Here is an example of a remote method on the server:
private void delete(int recNo) throws RecordNotFoundException, SecurityException { long lockCookie = hotelDB.lock(recNo); hotelDB.delete(recNo, lockCookie); hotelDB.unlock(recNo, lockCookie); }

Actually I love the thin client approach as I don't have to worry about the security of the lock cookie, and also what will happen if the client accidentally disconnect halfway and I have to timeout and unlock the locked record.
[ October 06, 2004: Message edited by: Paul Goh ]

Hey Marlene, after a night's sleep, I just realized that the "0" and "-1" recNo bug is actually not important in my application, because I am using a thin client approach (all locking is done on the database server side.), and the GUI client is never able to specify any recNo. So, all recNo are calculated by me, and they are always valid. No wonder the examiners failed to find any problem with that...

Originally posted by Marlene Miller:
Hi Paul,

Here is something I noticed in your lock method. It�s about a case where an invalid record number is passed.
long fileOffset = firstRecordOffset; ... fileOffset = fileOffset + ((recNo - 1) * recordOffset); ... if (fileOffset <= 0 | (fileOffset + 2) >= dbFileSize) { //(1) throw new RecordNotFoundException ...
I assume a valid recNo >= 1, since you subtract 1. I also assume recordOffset is the length of a record including the delete field.

If recNo == 0, at (1) fileOffset is firstRecordOffset � recordOffset.
Therefore fileOffset is probably > 0. An exception is not thrown.

If recNo == -1, at (1) fileOffset is firstRecordOffset � 2 * recordOffset
Therefore fileOffset is probably still > 0. An exception is not thrown.

By probably I mean, it is true if
the length of the metadata > record length (case recNo == 0) or
the length of the metadata > 2 * record length (case recNo == -1).

Marlene

[ October 05, 2004: Message edited by: Marlene Miller ]

Hey Marlene, I think you are absolutely right, very sharp. Luckily the examiners are not as sharp as you...

Hi Andy,

The check flag of 0x8000 is a flag for deleted records, required by the assignment. I found out that when I use writeShort(0x8000) on the RAF, I have to use readUnsignedShort() to get back the correct value. I didn't analyze this issue any further to see why this is the case, because it works, and it is good enough for me...

Anton: Please post to this thread when you get your results, I want to confirm if this is indeed the problem in my lock method.

Ok, I have removed the code for my unlock method, which is not relevant to the discussion anyway...

Thanks for the link!

Hey Anton, if I read the SCJD terms and condition correctly, I don't think you stand a chance for resubmit.

Mike: I didn't realize that I have violated the policies of this forum If you could kindly point me to a link where I could read up on the policies, I would really appreciate it as I do not want to make similar mistakes again.

Hey...to tell you the truth, I was shattered when I realized the mistake after I submit my programming assignment, but then, checking again for deleted record after the thread wakeup might be graded under the Data class rather than locking/unlocking (I got full marks for the Data class.). Also, I believe my GUI sucked big time (you might be shocked if you see how crappy my GUI is.), and my design considerations and documentation is nothing compared to the high standards that I have been reading in this forum, but it still turned out pretty okie. During the written exam, I was asked to name and justify my design choices, and quote some advantages/disadvantages of my design, and I turned cold, as I didn't even discuss about any disadvantages of my design in my programming assignment documentation.

However, I guess the one thing I did right is to read the assignment over and over again (Perhaps more than 30 times in total.) to make sure that I don't fail immediately. If you have been deligent in reading the assignment, I guess your chances of passing is very high.
[ October 05, 2004: Message edited by: Paul Goh ]

I think it would benefit other people if I post my lock method. Regarding unlocking after the record is deleted, I guess it is okie if the RecordNotFoundException is not thrown, as there are no side effects other than the unlock method removing the lock from the record. Actually, right after I submit the programming assignment, I realized that I have a problem in the lock method: I should have checked for deleted records again right after the thread wakeup, maybe this is why I lost so many points?

/** * Locks a record so that it can only be updated or deleted by this client. * If the specified record is already locked by a different client, the current * thread gives up the CPU and consumes no CPU cycles until the record is unlocked. * * @param recNo The record number to lock in the database. * @return A cookie that must be used when the record is unlocked, * updated, or deleted. * @throws RecordNotFoundException Indicates that the record is * not found. */ public long lock(int recNo) throws RecordNotFoundException { // Check if record has been deleted. try { // Lock the database file for sequential access. synchronized(dbFile) { long fileOffset = firstRecordOffset; long dbFileSize = dbFile.length(); // Calculate the position of the record to be locked. fileOffset = fileOffset + ((recNo - 1) * recordOffset); // Check that the position of the record to be locked is within // the bounds of the database file. if (fileOffset <= 0 | (fileOffset + 2) >= dbFileSize) { throw new RecordNotFoundException("The record is not available in the database."); } // Seek to the position of the record to be locked. dbFile.seek(fileOffset); // Check that the record to be locked is not deleted. if (dbFile.readUnsignedShort() == 0x8000) { throw new RecordNotFoundException("The record is deleted."); } } } catch (IOException e) { System.out.println("Problem reading from the DB file!"); e.printStackTrace(); System.exit(1); } // Obtain the lock to lockedRecords map. synchronized(lockedRecords) { // Check if the record is locked, if so, wait. while(lockedRecords.containsKey(new Long(recNo))) { try { lockedRecords.wait(); } catch (InterruptedException e) { continue; } } // Record has been unlocked, lock record and notify all. lockedRecords.put(new Long(recNo), new Long(cookieCounter)); lockedRecords.notifyAll(); return cookieCounter++; } }
[ October 05, 2004: Message edited by: Paul Goh ]

I would like to thank everyone here for helping me out, I would not have passed without your help...

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

1 month ago, I got so sick of doing SCJD that I literally forced myself to finish up and submit. If any expert is willing to take a look at my Data class to see why I did so badly in the locking, I would really apprecaite it.
[ October 04, 2004: Message edited by: Paul Goh ]