Win a copy of Rust Web Development this week in the Other Languages forum!

Charles Fung

+ Follow
since Jan 05, 2005
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Charles Fung


Say, I have these hotel rooms:
1. Hilton 2004-Oct-01
2. Hilton 2005-Jan-26
3. Hilton 2005-Oct-01

When the client searches 'Hilton' for booking, the view should ideally show #2 only , so the client cannot book rooms that have expired or beyond 48 hours from now. This also meets GUI usability consideration.

If the client searches 'Hilton' for deletion, the view should diaplay all three. This allows the client to delete any room for data cleanup.

My point is the search mechanism should be smart enough to handle this. I maybe thinking too deep and there are certainly other ways to work around it, but I found it to be challenging to accomplish this with the given DB interface.


Andrew Monkhouse: A GUI that allows search / view / book already shows mastery of many standard GUI design concepts. Adding an extra screen for create/delete/unbook will not really show any new GUI concepts.

I think the create/delete GUI imposes more design questions:

On the GUI side, assume that you use these typical CRUD workflow:
search / book
search / delete
The search in each case has a different criterion: search for book should return only valid entries that can be booked (room in the future, 48 hours rule, etc), while search for delete should return all entries that can be deleted (rooms at any time, booked rooms(?), etc). They may return different set of entries, but we have only one search(String []) method in the interface. You'll need some creative way to do it.

On the data server side, if you cache the records in memory, the create/delete will change the cache and that needs to be protected for thread-safety.

joel smither: There's no way that 2 clients could update the same record with this scheme is there?

I think you are right. However, other clients can read concurrently.

When I implemented the methods in my Data class, my filePointer variable is initialized once at start up (when I first open the file I read all the records in it and set the file pointer) and never modified again.

This is not true. Refer the documentation on RandomAccessFile. The underlying variable filePointer changes when you read, write or seek(). RandomAccessFile methods are not synchronized so they are not thread-safe.

doesn;t this mean I can't add the synchronized keyword to those methods?

Synchronized is implementation-related, it does not appear in interface. Rather, it is used in class, so you are free to add synchronized to the methods.

Originally posted by Paula Decker:
I call Data.close() from my gui controller to close the database if I'm in standalone mode. I call Data.close() from the server.close() method. Both the standalone client and the server use an instance of Data to make all calls to the database. I don't really like using the static but it should work. I was wondering if I should add it because close() is not in the DBAccess interface. What do you think?

I would use the following design:
(-> for reference; => for method call)
server->FileManager->file handle
server->DB (instantiate Data from FileManager)
FileManager has a constructor using the data file path, and provides access to the underlying data file.
=>shuts down server so no more client request will be handled
=>FileManager.close()=>close file and release file handle
The GUI controller follows similar pattern.
This allows use of DB interface instead of the Data class.
This would not need to depend on finalize() to close file. Finalize() is called on garbage collection. There is no guarantee VM calls finalize() on each and every object on VM shut down.
Note that server.close() should make sure no thread is writing to the data file while calling FileManager.close(). Otherwise, you may risk corrupting the data file.
Hope this helps.
Steve Chaloner:

the framework is now getting to the point where it's a project in itself

I would not think about making a framework for the client GUI. In general, I would stick with a minimal implementation and not over-engineer it. This is a one-time application, there is no appreciation for a framework. Rather, you may lose points if the code is considered to be too complicated, hard to understand and maintain, under-documented, etc.
Paula Decker:

I have just changed my code to add a public static method in my Data class called, close().

How does this work?
I am afraid it is not a good design to use a static method in class Data to control instances of Data.
Also, the assignment defines an interface DB, so the server should rather reference DB interface to hide the implementation, than reference directly the class Data.
What do you think?

so I still don;t understand why the update method needs to be synchronized.

To decide if a method should be synchronized, I would question:
1. would there be multiple threads in the VM? => YES for this client server application, every client request spawns a thread.
2. would this method access shared resource? If yes, would there be adverse effect when this and other methods access the resource?

In this assignment, the very basic shared resource is the data file. There should always be only one thread accessing it. Depending on the design, you might also need to protect cached records in memory and their lock status.

There are two criteria if update() does not need be synchronized:
1. The update method changes the data file using another object and that object protects the data file properly. If not, update() HAS to be synchronized.
2. The update() and read() methods do not have conflict. We know that update() touches only one field, so the change is atomic - either the field is changed or not changed. Otherwise, if update() touches more than one field, read() may read a record that is partially changed and that is not good.
IMHO, given update() accepts a String[] parameter, I would tend to make it generic (assuming changes to multiple fields) and synchronize it.
Finally I got a reply from Sun and my score on has changed from Fail to Pass.

I have read many posts on this forum while I was working on the assignment, and that has been very helpful. Thanks to all of you who have contributed to this forum!
17 years ago
This is the breakdown for my test:
(I masked the registration number and the site number)

Test: Sun Certified Developer for the Java 2 Platform (310-027)
Date Taken: 2004-12-31 09:09:26.467
Registration Number: xxxxxxxxxx
Site: onxx
Grade: F
Score: 368
Comment: 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.
Section Summary:
Section Max Actual Points Points
General Con: 100 92
Documentation: 70 63
OOD: 30 30
GUI: 40 33
Locking: 80 80
Data Store: 40 40
Network Server: 40 30
Total: 400 368

I am informed by Prometric that this is now referred to, and I have to wait for their response.
17 years ago
I just discovered that I got a failed grade on my test, but the details show a score of 368 out of 400. There is a breakdown of the scores for each section and no reason given for a failure. I have sent a query to Sun.

Have you ever heard of something like this?

[Andrew: changed title so it makes more sense in Sun Certification Results forum]
[ January 10, 2005: Message edited by: Andrew Monkhouse ]
17 years ago
Does the instuction specify the value of the cookie? What do you compare it with?
It does not even say that it is a constant. It can be some generated number that satisfies a secret algorithm. I would just read the cookie and do nothing about it, and leave a comment in the code for maintenance purposes.
On reading the data file, any unexpected data should cause the server program to stop and back out.
I also suspect the 44/80 on locking is due to unhandled orphan lock.

These are the scenarios I can think of, and should be handled:
If a user locks a record and then it crashes, can the server detect it and undo the lock, allowing other user to lock that record? The same user may restart the client and try to lock the same record. Can the server handle it?
Further, if a user locks a record and the server crashes, can the server, on re-start, forget about the previous lock on the record?
I do not quite agree. If you read carefully, the requirement is under Network Approaches. 'In either case...' refers to the RMI and serialized objects over socket approaches.
'must allow the user to specify the location of the database, ' means that the client program should be able to specify the location of the server program, i.e. the computer that the server program is running.
In practice, the server must be running before the client starts. When the client starts, you need to tell it where to connect to. The requirement is to prevent hardcoding the server machine.
Also, it is not practical for the client program to specify the location of the database file on the server machine. If you allow the client to specify where to get the database file, different clients may be reading from different files, and that is bad.