Request For Comments

[Ben Nichols]

I am getting ready to submit my assignment for fly by night.
Below is the overview summary for my major design decisions.
If you feel that I am in error, please challenge me, because I would like to discuss my decisions, in order validate them, and in order to prepare for the essay test.
<h2>Issues</h2>
Record Locking - record locking is the responsibility of the client. The server blocks new lock requests
until the lock is available. If the client does not unlock the record, the server retains a lock on that record,
and blocks, effectively locking the client, any additional request for a lock on that record. <code>suncertify.db</code>
is threadsafe if interfaced with as intended.


Thread Safety - thread safety between the client and server is managed by rmi, rmi starts new threads for requesting
clients as needed.


Networking Choice - networking decision is rmi, because it takes less code to implement, and is easier to debug


Search Algorithm - Search algorithm searches database in <code>O(cn)</code> time for multiple field matches where
<code>c</code> is the number fields being searched, and <code>n</code> is the number of records.
This is as efficient as possible without building index tables into the database for every field possibly searched.


Expectation of future functionality enhancements - the GUI was built to dynamically build itself around the
current contents of the database. This will allow the GUI to interface with server-side changes to the database and its
schema seamlessly. GUI actions are implemented through dialog boxes, and menu items. If a new version of the GUI with more
actions is developed the way the user uses it will not change significantly.

[Paul Carroll]

It may be advisable to look at the example questions at http://suned.sun.com/usa/certification/devsq.html. For example there is a list of pros and cons of RMI when compared to the sockets API. Also I would strongly recommend the Java 2 certification study guide by RHE as the last chapters cover the SCJD.
P.S. No timeouts on the client locking (?). Does that mean if there is a problem with the network, disconnected clients won't be able to adjust values within the database.

[Ben Nichols]

The <code> public void lock(int) </code> function is required to block until a lock can be obtained. A timeout period would would have to be hard coded, and is easily done. But do you feel that it would it would put data integrity at risk if there was a network delay that exceeded the timeout? Also shouldn't timeout be parameter to the program. (Which would violate the command-line requirments)

[Paul Carroll]

I would set the timeout to a value larger than any possible network delay. (I'm not sure if Java 1.2 can tell if a link to a client has been partially disconnected or disconnect but this would be the ideal solution). Also the timeout parameter could be a configurable item within a seperate file (similiar to an .ini).
Just an idea.

[Ben Nichols]

RMI Server side can catch RemoteExceptions.
I could catch RemoteExceptions in lock, unlock, and modify, and guarantee that the server unlocks the record if there is a remoteexeption during that process. My concern is that there is a read operation mixed in to double check the number of seats prior to modifying. If a failed read operation unlocked the record then it would be possible for a normal failed read to unlock a record that should be locked, violating data integrity.

[Rao Kuna]

Hi Ben
I have a question regarding the UI you have developed.
Did U implemented specifically and design pattern like MVC for UI. If yes, did U use all swing components with their respective model interfaces ? By reading about the UI requirements, I feel we need to have UI with a separate control scheme, so that the future expansions will not get effected. What do U say ?
Rao

Networking Choice - networking decision is rmi, because it takes less code to implement, and is easier to debug
Search Algorithm - Search algorithm searches database in <code>O(cn)</code> time for multiple field matches where
<code>c</code> is the number fields being searched, and <code>n</code> is the number of records.
This is as efficient as possible without building index tables into the database for every field possibly searched.

Expectation of future functionality enhancements - the GUI was built to dynamically build itself around the
current contents of the database. This will allow the GUI to interface with server-side changes to the database and its
schema seamlessly. GUI actions are implemented through dialog boxes, and menu items. If a new version of the GUI with more
actions is developed the way the user uses it will not change significantly.
[/B]

[Ben Nichols]

UI is where I get extremely ignorant. As a fledgling Java (and UI) Programmer, I don't really understand what the assignment requirements mean by a 'control scheme.'
I used a JTable and an underlying TableModel to build my UI.
The TableModel looks like whatever the db looks like.
That was as far as I got to extensibilty.
I know that remote class loading means that the GUIClient can be opened from anywhere, meaning that a current copy can reside somewhere on the web and updates will be controlled and simple.
If a control scheme were to mean anything to me it would be a non-code enforced guideline for adding features to the client. If you concur, I will add this to my program documentation.

[Rao Kuna]

I was looking at RHE book and the topic, other Design Issues also say about we need to use some kind of Design Pattern like MVC. I was earlier thinking JTable implementation alone can meet MVC requirements but what else can be included ? It would be better if anyone who already cleared the exam can give us feedback.
Thanks
Rao

[Ben Nichols]

I'm fairly certain that using a swing Jtable and its corresponding abstracts to build the GUI covers the MVC thing. I couldn't tell you why but I do recall having looked into it. What I don't understand is the phrase 'control scheme' and whether it applies to the MVC thing or whether it transcends java.

[Rao Kuna]

Ben
I think, I should agree with U. "Control Scheme" is a part of MVC (model-view-control) design only and JTable's abstract model include MVC design. As U said, It would be better idea to document the decison.

Originally posted by Ben Nichols:
I'm fairly certain that using a swing Jtable and its corresponding abstracts to build the GUI covers the MVC thing. I couldn't tell you why but I do recall having looked into it. What I don't understand is the phrase 'control scheme' and whether it applies to the MVC thing or whether it transcends java.

[Balaji]

Hi,
I am in the process of taking the Developer Certification.
Could any only me about websites from where i could get the necessary information.

[Mahesh Hegde]

Hi Ben,
I have a doubt on the record locking scheme. From your description it looks like for doing some writing / reading your client follows the steps:
1. call server.lock()
2. Read/Write
3. call server.unlock()
What hppens when the client terminates anywhere before step 3. The server will have the lock on and no other client will be able to read/write from the locked record.
I would think that all the 3 steps should happen as an atomic operation on the server side. Say your client calls server.read(), then within read you should :
1. lock()
2. read data
3. unlock()
But the disadvantage here is that if lock() in read() blocks to obtain lock, then client will just wait, probably frustrating the user. But this will at least maintain data integrity.
Correct me if I am wrong on understanding your design.
-mahesh

[Ben Nichols]

I would agree, except the client class is supposed to implement all of the public functions of the data class. This suggests that data processing (reads/writes) should happen above the client level.
Additionally, the server should be totally dataset independant, meaning that the server shouldn't be allowed to validate data, or even care what data is being updated, or know what the database looks like.

[ravi janap]

Record Locking - record locking is the responsibility of the client
I feel that record locking must be the responsibility of server rather than client
-- Ravindra

[Najib Coutya]

Both solutions were definitely accepted by Sun.
If you pick up the server one than
lock
book
unlock -- in a finally
I think is an atomic solution. Cause even if the client crashes the record will be unlocked.
If you pick up the client one, there are many variations, but in my opinion you should have a time out so that if a client crushes the record booked by the client doesn't lock for ever.
Cheers
Najib