passed SCJD

[Xiao Di]

They just posted the result listed below, and thanks everyone!

This report shows the total number of points awarded for each section. The maximum number of points is 400, to pass you need a score of 320.

General Con: 100 90
Documentation: 70 70
OOD: 30 30
GUI: 40 26
Locking: 80 80
Data Store: 40 40
Network Server: 40 30
Total: 400 366

[Sam Codean]

Congratulations!!
Enjoy the joy while it lasts. So what next ? Preparing for another one?
BTW You got a good score on locking, can i ask how was the design like?

[Ed Tse]

May I ask how do you handle locking in ensuring only the client who locked the record would be able to delete/update the record?

[Xiao Di]

I have no idea why I lost points at General Concern and GUI, but I think I might know my fault at Network Server. Here I am sharing it with you and wish no one here would repeat the stupid mistake again.

I did not know rmiregistry can be launched programmatically by calling LocateRegistry.createRegistry(). So in the user guide I asked user to open a DOS window and start rmiregistry manually.

[Mikalai Zaikin]

Congratz !!!

[Xiao Di]

Hi Sam Codean and Ed Tse, thank you for replies. As you requested, here I'd like to talk a little bit about locking.

Andrew, please feel free to let me know or even modify/delete my post if I talked too much and violated the policy of this forum.

The first thing to implement locking is to identify clients. (It is connections in my case. I allowed multiple connections even if from a single client. Of course, I documented my design and explained why.)

The DBMain interface does not carry any info about who is the client sending the request. You need to figure out a way to pass client identity through it. And your design should fit both remote and local databases.

The second thing is to mark a record as locked or not. With this mark you can tell whether a record is locked and use it to prevent other clients operating on it. For example, a locked record can not be updated and deleted by other clients.

The last thing is to add client identity into the mark of lock. You need this info to tell who is the owner of the lock, and only the owner can release the lock.

All above is about the minimal requirements. In practice, a client can lock a record and hold it for a while. Your solution should allow other clients to read the record during this period. That means you need handle the conflicts between read and write accesses besides the lock which only good for the conflicts between write and write accesses. (I designed an additional short-term lock to handle that. It can be shared among read accesses and grant a higher priority to write access. Any way, this additional lock is not visible to clients.)

Hope it helps.

Cheers!

[Xiao Di]

I am not sure whether posting source codes is allowed here. If yes, I'd like to share my Record class with you guys, in which class all locking mechanism is implemented.

[Ed Tse]

Posting source code is not allowed.

Please elaborate on "The DBMain interface does not carry any info about who is the client sending the request. You need to figure out a way to pass client identity through it. And your design should fit both remote and local databases."

[Andrew Monkhouse]

Congratulations Xiao

We typically only allow very small amounts of code to be posted. We certainly do not allow posting of more than one method in any area where there are major points awarded.

However talking about the concepts is allowed, as is psuedo-code (as long as it is properly abstracted). We even allow large amounts of code to be posted if it is not directly related to the assignment (for example, you could post an entire locking solution as long as it cannot be used in the real assignments without the reader making major modifications after understanding the concepts). Those last two can be quite hard to write after you have working code though. Usually it is easiest to just talk about concepts as you have been doing - that is also safest.

Regards, Andrew

[Xiao Di]

Thanks Andrew for clarifying the policy!

[Xiao Di]

Originally posted by Ed Tse:
Posting source code is not allowed.

Please elaborate on "The DBMain interface does not carry any info about who is the client sending the request. You need to figure out a way to pass client identity through it. And your design should fit both remote and local databases."

1) public String[] read(int recNo) throws RecordNotFoundException;
2) public String[] read(Object clientID, int recNo) throws RecordNotFoundException;

The 1) is from DBMain and the 2) is just an example. Obviously the 1) does not carry client info.

The point is that how to pass additional info/data through an interface. Changing interface as shown above is one of the ways.

[Ed Tse]

I didn't know we can overload the default interface to solve what they want.

I thought
// Locks a record so that it can only be updated or deleted by this client.
// If the specified record is already locked, the current thread gives up
// the CPU and consumes no CPU cycles until the record is unlocked.
public void lock(int recNo) throws RecordNotFoundException;

then all I can solve the lock problem is by using

public void delete(int recNo) throws RecordNotFoundException;

[Jimmy Persson]

First I would like to congratulate Xiao Di for passing the exam.

Next I have read the posts about the lock mechanism. Here is how I have solved it, please comment.

As I see it I'm the developer and I decided that all calls to Data(and the db-file) shall be done through my business class called DatabaseClient. Both the network and non-network db-access is done through this class.
And to ensure that all instances of DatabaseClient works on the same Data my class Data implements the singleton pattern.
So when the user request either delete or update the DatabaseClient first locks the record, performs the task and unlocks it. Since they all work on the same instance of Data I ensure that only the client that locked the record can update/delete it.

[Ed Tse]

Jimmy, your way is good. You have a business layer to abstract away from db manipulation. However, I am still confused whether there is a requirement to handle "Do not allow a client to delete if he/she doesn't have the lock" in the DB layer. The database class is supposed to be implemented in a way that is reusable.

[Zhixiong Pan]

Jimmy, can you tell me the relationship between your DatabaseClient and Data? I guess in DatabaseClient there are methods such as search(), searchAll(),book() and isBook() which are recombined from methods in Data.

[Andrew Monkhouse]

Jimmy & Zhixiong,

It is normally considered bad etiquette to hijack somebody else's thread. This thread should stick to Xiao's topic(s) - talking about passing SCJD and passing along hints.

Regards, Andrew

[Andrew Monkhouse]

I have moved this topic to the Sun Certification Results forum.