SCJD Grade : P

[J. S. Lee]

I have passed SCJD with 375/400.
CertManager said, "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 0f 320. Section Summary: Section Max Actual Points Points General Consid: 100 75 Documentation: 70 70 OOD: 30 30 GUI: 40 40 Locking: 80 80 Data Store: 40 40 Network Server: 40 40 Total: 400 375".
I believe I have good knowledge at object serialization, but I tried RMI, which was relatively unfamiliar territory. It turned out to be great. I implemented just three classes, an interface, a server and a RMI class, for server side. I should say that the interface was almost same as it was, and the server and RMI class had only four and a couple of lines respectively.
I did get quite amount of help from SCJD forum. It was unbelievably helpful. Thank you very much.
J. S.

[Mark Spritzler]

Congrats J.S. Great score.
Can you elaborate on your locking design?
Mark

[Andrew Monkhouse]

Hi J.S.
Congratulations.
Thank you for elaborating on your design. Please do not post any more code though - this is already dangerously close to a complete locking solution.
Would you care to comment (in words, not in code) whether you had a "bookRoom()" method on the client side or on the server side? And if you had it on the client side, did you check for crashed clients?
Regards, Andrew

[Tony Collins]

Congrats cracking score .
Could you elabarate on how you shut the server down.
Tony

[J. S. Lee]

I am sorry. Here is NEW one.
The interface provided has methods below:

        public long lockRecord(long recNo) throws RecordNotFoundException;
        public void unlock(long recNo, long cookie) throws SecurityException;

Mutual exclusion and no busy waiting have been done by

                        lockCookie=random.nextLong();
                        while(isLocked(recNo)){
                                try{
                                        wait();
                                }catch(InterruptedException ie){
                                }
                        }
                        RecordLock RL = new RecordLock(recNo, lockCookie);
                        recordLock.add(RL);

in lockRecord(long recNo), and

                        //searches and removes
                        for (int i=0;i<recordLock.size();i++){
                                RecordLock RL = (RecordLock)recordLock.get(i);
                                if (RL.isMatch(recNo, cookie)){
                                        recordLock.remove(RL);
                                }
                        }
                        notifyAll();

in unlock(long recNo, long cookie).
As you can see, I internally used some functions, which were for monitoring locked records. Vector is used, Since it is the easiest way to implement.
I should have used notify() instead of notifyAll(). I am a lazy guy. Since it was not required, I just ignored it.
I hope it will help those who are seeking some help from the JavaRanch as I was.
P. S. It is �URLyBird�. I guess someone knows what the quoted means.^^
J. S.

[J. S. Lee]

The interface provided has lock() and unlock() methods that are public, so I assumed that the client should call those methods. If they wanted us to use those methods on server side, why would they make the interface with those public methods? I guess�that is the way it should be.
I should have cared deadlock situation when clients crashed, but I did not... Since it was not explicitly mentioned, I just ignored it.
In order to handle recovery from deadlock, deadlock avoidance etc., I think� you need to have some kind of agent such that it does monitor network periodically and if clients crashed, the agent executes recovery process from deadlock. Of course, you should have extra code to monitor and some heuristics for time interval etc., but I have good news. Since it is not distributed system, it would be whole lot easier.
As far as I know, they want us to implement mutual exclusion and no busy waiting. However, I mentioned that deadlock should have been cared in the choice.txt.
Please comment on this. Since they mentioned that no extra point would be granted because�, I did not want to go deep.
J. S.
[ September 06, 2003: Message edited by: J. S. Lee ]

[J. S. Lee]

In my assignment they require three arguments, (nothing), alone, and server be implemented. Therefore, I did not implement anything other than those. I just used Ctrl+C to shut the server down.
J. S.

[Andrew Monkhouse]

Hi J.S.
I am a bit worried about this entire thread. It gives Mark too much ammunition for his "simple is best" arguments
Seriously though - your score shows that you definately had the right attitude to dead locks and dead clients. Congratulations once again.
Regards, Andrew

[Fisher Daniel]

Congratulations to you...
daniel

[Mark Spritzler]

Originally posted by Andrew Monkhouse:
Hi J.S.
I am a bit worried about this entire thread. It gives Mark too much ammunition for his "simple is best" arguments
Seriously though - your score shows that you definately had the right attitude to dead locks and dead clients. Congratulations once again.
Regards, Andrew

I don't need any more ammunition. I already have over two years of it. And it is always the same. Those that kept it simple get the higher grades. Simply because they didn't add complexity and additions that went beyond the scope of the requirements, and therefore caused them to lose points.


Mark

[Vlad Rabkin]

Hi J.S.,
Congratulations!
Could could please also comment
1. How did you generally synchronized methods to access the database (read/update/create/find):
- did you use ReadWriteLock or you have just synchronized all methods in DB interface implementation (or Server implementation)?
- where have you done this: in DB interface implementation directly or in Server interface implementation?
2.
- Have you hard-coded database column information (e.g. field length and so on)
- or you added some methods to the server interface,
- you just added some methods (like getMetaData()) to DB interface,
Please don't provide any code, just give us the idea how you solved this problem!
I will really approciate your help!
Many thanx,
Vlad

[J. S. Lee]

Hi Vlad,
1.
Are you talking about possible IO problem on the server side? Let me assume it is.
JVM is an application in OS point of view so that it does not take over file system that is pure kernel territory.
Some JVM like windows JVM maps a thread to a kernel thread and most of modern OS is time-slicing system so that it might be the case that OS halts an executing thread and then executes another, and then eventually messes up the whole file system. Even though it happens, you do not need to worry about it because JVM prevents waiting threads from being executed as long as you have appropriate locking mechanism. I guess it is what they wanted us to do. Therefore, I did not implement additional code.
2.
It is up to you. Even though I had an additional class to seek the read/write position easier, I doubt that it will be reusable.^^
Any comment?
J. S.
[ September 09, 2003: Message edited by: J. S. Lee ]