Yupp Cook

Ranch Hand
+ Follow
since Feb 07, 2006
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
In last 30 days
0
Forums and Threads

Recent posts by Yupp Cook

Thanks.

Hummel, Nicholas: If any next target could be Sun Certified Web Component Developer (SCWCD). But first I need long long break...

Anybody knows aobut the SCWCD? Is it as hard as SCJD?
17 years ago
Congrats Bill!



See it that way, you got 336/400 = 84%
Sounds damn good.

Regards
Yupp
17 years ago
Hi everybody.

I passed the exam.
It took them only a week to score though I was prepared to wait another couple weeks.

Here's my result:

Score: 348
The maximum possible score is 400. The minimum to pass is 320.
General Considerations (maximum = 100): 100
Documentation (maximum = 70): 70
O-O Design (maximum = 30): 30
GUI (maximum = 40): 24
Locking (maximum = 80): 44
Data store (maximum = 40): 40
Network server (maximum = 40): 40

I lost most the points in locking even though I thought it to be 100%. I don't know exactly what went wrong, but I guess it's because I used notify() where notifyAll() would have been appropriate. In addition they might not have liked my explanation on that choice.

Likewise I can only guess why I lost points on Gui. Instead of combo boxes I used text fields to choose the search criteria. The user has to type the criteria or can copy it with a doubleclick from a cell in the JTable. Doing so I avoided the initial filling of the combo boxes. I admit I was to lazy to invest more time doing the combo box way.

I spent almost a year to finish but with a 9 months break. (No you are wrong, no pregnancy! )
Choices.txt is 21 KB
Userguide.txt is 4 KB
A problem was that I had a break of 4 weeks between submitting and the essay. I advise you to avoid such a long time in between and do the essay as soon as possible. I spent one sleepless night to review all the code before the essay.

Thank you all ranchers and everybody who disussed with me. It's a great forum which often helps by just searching and reading.

Any question you have, feel free to ask...

Regards, Yupp.
17 years ago
Congrats!
I'm waiting, too.
I think it's the same link where you uploaded.
https://www.certmanager.net/sun_assignment/assignment.html
login - then go to history.

Regards
Yupp
Hello ranchers!

I finally took the essay exam today. About 2 weeks ago I submitted the project Now the nervous waiting period for the result starts. Any advice how to prevent me from chewing my finger nails off?

Questions weren't to hard, more or less what I expected. It's advisable though to take a real close look at the project before sitting the exam.

Regards
Yupp
I found it myself.

logger.setUseParentHandlers(false);

turns Console logging off.

Thank you anyway.
Hi thanks for your response.
I decided to use logging.

Problem now it doesn't only log to a file but also the console.
I ve no idea how to turn console logging off. I tried to remove all Hanlders but there aren't any.

Any idea? This is a code fragment:

private static Logger logger = null;

static {
logger = Logger.getLogger("suncertify.Logger");
Handler handler;
try {
handler = new FileHandler(Constants.LOG_FILE, true);
}
catch(IOException ioe) {
System.out.println("File logging not initialized.");
System.exit(0);
}

handler.setFormatter(new SimpleFormatter());
logger.addHandler(handler);
logger.setLevel(Level.ALL );
}
Hi all ranchers!

I have 2 questions. First concerning logging:

(1) Is logging required even though not explicitly mentioned in the instructions? If so, logging on server AND client side is necessary?

(2) My instructions:
You must provide basic user documentation...This documentation must be in one of these three formats:

* HTML
* Plain text (not a wordprocessor format)
* Within the application as a help system.

All the gui examples presented here have the user documentation within the application as a help system. Would it be bad style to just add a plain text file realizing the 2cnd possible choice. So the gui would remain without any file menu.

Thanks for your opinions.
Y.
Couln't see anything like this in my spec(BS_2.1.2).
My records appear always in the order of recNo.
I think you don't get credit implementing a sorting mechanism.

Y.
Hi Alan


Originally posted by Alan Morgan:
Ok Yupp I think I understand you now.

I believe mine works the same but I have to run some tests later to prove it.
So do you have a section in your choices.txt on deadlock ?
And if so do you say something simple like
"Deadlock is avoided as only 1 client can lock 1 record at any 1 time
This is acheived as the client blocks on each request...."

or something along these lines ?

Thanks again,
Alan.




I'm about to finish BS2.1.2 but still haven't started the choices.txt. I ll try to explain how it's achieved looking at the inside of Data, my logic layer and the fact that the client only permits one request at a time.
Would be interested how others handle this..? :roll:




Originally posted by Alan Morgan:
Ok so I ran my tests and it seems that the blocking is working in the same way for me.

I put a bit of code into my server so that if you try to lock record 1 it hangs effectively.
So with the same client you can't do anything as the result is being waited on.
This tells me that if my lock/unlock occurs in one call from a client then a client can only lock one record at a time.

Just to check I had a second client connect to the server and try to lock record 2 and that worked fine.

How does this sound ?




Sounds good. I will test my server with numerous test clients all accessing the same records. But haven't done it yet.

Originally posted by Ronald Wouters:


In my URLyBird implementation, when starting the URLyBird server, the user is also shown a "server gui" where they must enter the location of the database file (JFileChooser, on the server machine) and also a port number on which the RMI registry will listen. These properties are also saved in the suncertify.properties file so the user doesn't have to enter them the next time they start the server.



Hi

2 Questions

(1)
I thought like Hans that no server gui is needed so my question is:
What should happen to the server gui when configuration is finished?
Closing it just keeping open the prompt window?

(2)
Rereading the spec of BS2.1.2 it says:
All configuration must be done via a GUI...
Could the character encoding also be considered to be part of the configuration? So far I define it in an interface called Constants.java

Regards
Yupp

Originally posted by Alan Morgan:
Yupp - After having a read of this thread

https://coderanch.com/t/187162/java-developer-SCJD/certification/Dealing-Deadlocks-Stale-Locks

I got to thinking about what you said again.
In this thread John Smith says:



So its seems to me (correct me if I am wrong) that he took the same approach as you.
One question - how exactly do you "block until the record is booked" ?

Oh nearly forgot - are you fat or thin client ?
So is your book() call on the server or client and do you think it makes a difference either way ?

Thanks again,

Alan.

[ March 15, 2006: Message edited by: Alan Morgan ]



HI Alan

It is the same approach! Having read the comments by John Smith encourages me.
I implemented a thin client architecture. I know you have a fat client, but the way to make sure only one record
can be booked at a time should be the same:

Let's simplify the book process to explain it easier. Clicking the book button calls the actionPerformed method.
Before this method ends (1) it sends the request AND (2) receives the result AND (3) updates the gui. Meanwhile no other action is technically possible - the client is blocked cause it's waiting for the method to return. That's all. It doesn't require any further programming effort.

Basically it looks like:
public void actionPerformed(ActionEvent e) {
Result result = book(infoFromGui);
client.setResult(result);
}

If one day I want to allow locking various records I'd have to seperate the 3 steps into different methods.
The actionPerformed would end before the result is back allowing the next locking action. The dead lock danger would arise.

Yupp
Even better it seems to me

using registry.rebind(...) instead of registry.bind(...)
avoid the AlreadyBoundException

Regards
Y
I think both ways(unique and duplicate recs) are reasonable.
Duplicate records can be considered senseless cause the database represents just an "is" booking state without any date relation. So what's the point of having the same record twice?

I go for DuplicatKeyException.

Yupp.
[ March 14, 2006: Message edited by: Yupp Cook ]

Originally posted by Alan Morgan:


Damn that devil and his advocate...he's right again, which means more work for Alan

You're right, what I will do is have the Data.lock method which invokes LockManager.lock check if the record is still valid after the lock is received.
If not I will release the lock and throw a RecordNotFoundException.

Good catch.

Have you started thinking about deadlock avoidance as yet ?
If so any chance you could have a look at the conversation Yupp and I were having above and throw your two-cents into the mix.

You're a useful man to have around....as yet untouched by the evils of coding, so I can get a "pure" opinion off you




Hi Alan

Fine.


That's similar to what I was trying to tell you in my postingin from February 12, 2006 04:38 PM

There s still some improvement for your lock workflow.
Now your plan is (correct me if I m wrong):
while isLocked(recNo) {
wait
}
lock(recNo)
ifNotValid(recNo) {
unlock(recNo)
RecNotFndExc
}

Improved:
while isLocked(recNo) {
wait
}
ifNotValid(recNo) {
RecNotFndExc
}
lock(recNo)

Both are synched on LockManager.
My advice is to check the validity before locking, so you will never lock a invalid record.


The deadlock problem:
I see problems getting a reliable client id which doesn't change under no circumstances.
So in my aproach the client could actually lock various records, but I prevent him from doing so not allowing further actions after a request was sent. I prever this way cause it s more flexible. What if one day booking of various records is favored. No major Data.java changes would be necessary then. Are there any problems I don't see?

Did I explain it well? I ve the feeling the more I work on this the more complex it gets. :roll:

Regards
Yupp