Maybe a First! Got my results in 6 days :)

[Serkan Yazici]

I was expecting a long wait for my results since I took the essay exam last friday May 28th (and uploaded my assignment the day before). But what a surprise; Got my assignment score today (thursday June 3rd). Must be a first

I'm not 100% happy with my score but I think I'm being a bit of a geek:

Score: 393
General Considerations (maximum = 100): 99
Documentation (maximum = 70): 69
O-O Design (maximum = 30): 30
GUI (maximum = 40): 35
Locking (maximum = 80): 80
Data store (maximum = 40): 40
Network server (maximum = 40): 40

I would love to know what kind of a general consideration point I've lost, and I'm surprised my GUI lost points.

Thanks to everyone in this forum; searching the forum saved me a lot of time to form some design ideas and helped me to fix small things like not setting an RMI security manager to avoid access exception (virtually all RMI tutorials do that).

Good luck to anyone else thinking about/preparing for the assignment or waiting for their results.

-- Serkan

[Philippe Maquet]

Excellent score, Serkan! Congratulations!

[Vishwa Kumba]

Congratulations!

[Guvenc Gulce]

Tebrikler Serkan

Would you please tell us a bit more regarding the locking mechanism
that you have used ? this part seems to be the most bothering part
in the assignment. did you implement create()/delete() methods ?

Great Score !

Guvenc Gulce

[Serkan Yazici]

Thanks all,

My locking mechanism was slightly different than what I've seen discussed in the forums (might have missed it though). Here is a brief explanation:

Locks were maintained inside Data class using a static synchronised hashmap.
The hashmap kept record numbers against a RecordLock object which contains
the lock owner and an immutable (final) object. I used this final object to
synchronise on and wait if a record was already locked. Since each locked record now has its own queue (monitor), releasing a lock doesn't wake up all the clients that might be waiting for other records (which would happen if I synchronised and waited on hashmap itself).

I didn't make lock/unlock methods syncronised, also the hashmap is never synchronised either (it is already created as a synchronised hashmap) to prevent unnecassary blocking.

However, I was careful to avoid possible threading problems like:

    if (lockList.containsKey(key)) {
        Object value = lockList.get(key);
        ...
    }

Where the key could be removed after finding out that it exists, and before getting its value. So I accessed the hashmap with a single call:

    Object value = lockList.get(key);
    if (value != null) {
        ...
    }

Your lock/unlock interface might be different and require other ways of dealing but my general advice on locking would be to minimise any unnecessary blocking caused by a lot of synchronisations (only synchronise on the object you wait), and trying to make your wait/notify calls as efficient as possible (waking up only the relevant client(s) etc.).

Hope didn't give away all the goods
[ June 03, 2004: Message edited by: Serkan Yazici ]

[Vishwa Kumba]

Originally posted by Serkan Yazici:

However, I was careful to avoid possible threading problems like:

That was smart.

[Baris Dere]

Tebrikler Serkan,

What a score !!!

Did you see your score at CertManager? or somewhere else?

Regards

Baris Dere

[Hanna Habashy]

Congratulation

I have a simple question:
When a client accessing the server, can the client choose which database to access on the server. Or the client can choose the database only in a local mode.
My instruction is totaly confusing:
her is what it say, if you can help me understand:

the program must allow the user to specify the location of the database, and it must also accept an indication that a local database is to be used, in which case, the networking must be bypassed entirely. No authentication is required for database access.

Does that mean the user can choose a database to access on server mode?
[ June 03, 2004: Message edited by: Hanna Habashy ]

[Serkan Yazici]

@Guvenc: One thing I forgot to mention, I've implemented create and delete both in my Data class and in the GUI as well. GUI dialogs for create/delete are not required and may have caused my GUI score being reduced; but I doubt it. I've tested them thoroughly.

@Baris: My score/details are only shown at http://www.certmanager.net/sun_assignment/ at the moment CertManager still says it is pending. I'm not in a hurry though.

@Hanna: In my implementation, network client only allows host/port selection of the server. Database file for all network clients is same and chosen only when starting the server. IMHO, It doesn't make sense to have server open different files for different clients. Also, how are you going to choose a file which might reside on a different machine (maybe even across the globe).

[Andrew Monkhouse]

Congratulations Serkan

[Jesse Jesse]

Well done Serkan, great score!

Can you give me a few hints on how you implemented your db access. Did you read and write direct to the file by using a RandomAccessFile or did you use some form of cache. I have being thinking over the pros and cons of each.

Thanks

[Serkan Yazici]

Thanks McManus,

I think this was discussed in length in the forums and both approaches can get full marks as long as you mention why you followed the particular approach you've used in your design document.

In my case, I didn't use a cache and accessed the file for each read/write operation. For small number of records, I think the cache doesn't provide any real performance benefits unless you are running your application on really old hardware/OS. Most new harddisks come with 8mb cache on board, and modern OSs also buffer I/O access on free memory. So adding my own third level cache didn't seem logical considering it actually prevents scalability and you have to manually keep cache/file in sync.

On the other hand, you may argue that this is a learning exercise, record numbers will never be too high, your algorithms make better use of a memory cache rather than disk I/O, 90% of operations will be read operations so updating the file infrequently is not a big problem, etc...

Choice is up to you, just make sure to mention it in your design choices document with a paragraph or so.

-- Serkan

[Jesse Jesse]

Thanks Serkan

I think our paths may have crossed before does UNL ring any bells(maybe not).
One more question if thats ok? Just wondering how you approached your assignment(mine is URLyBird) from an oo point of view. Did you introduce into your design objects to represent the main entities, lets say in may case a RoomBooking and extra objects that and for example a BookingMgr that would take care of communicating with the db classes etc, mapping the types the db uses from a String[] array to a RoomBooking etc. Or did you just leave it as is by passing say a String[] back to the client for display. Did you feel there was a need to introduce this level of abstraction into your design if you did?

[Serkan Yazici]

Hi McManus,

Yeah, I was working/doing my PhD at UNL (now London Metropolitan University). Were you a student there?

About your question; I had three layers for getting record data from the database to the client interface;

1) Low level access (Data class -> DataAccess interface)
|
| String[]
V
2) Data Model (using Layer 1 directly or through network)
|
| Record collection
V
3) Client View

Between layers 1 and 2, I kept the simple String array format to pass data. Data Model then processed the data, implemented any business methods (simple things like refining search results, booking, etc) and gave layer 3 (Client) a collection of Record objects as results. As you can see I only used a wrapper entity (Record) between Client and Data Model mainly because to hide some low level details such as the physical record number from the Client.

I suppose I could have defined a Contractor bean class instead of a Record wrapper class but I was too lazy. Record wrapper simply encapsulated the string array as it was and the record number; no individual name, location, etc fields. Saved me from writing a dozen getters/setters I suppose writing separate bean classes for your entities is more OO; but a single wrapper like mine is not tied to the changes in fields.