design comments ...

[Dan Myers]

Hi all,
i have just started for my FBN design, and appreciate comments to it.

Clientside classes:
===================
*FBNClient class
-handles GUI,table, search area
-starts dialog and questions if in local or remote mode befor presenting the client GUI
-holds a member ,a reference to the IDataAccess which offers the business logic.
when is in local mode the FBNClient creates a new object of LocalData direct.
when is in remote mode, asks the Connection Factory on the server for a new RemoteData
object.
Database classes:
=================
*existing classes from SUN
(Fieldinfo, Datainfo, Exception)
*Data class
-implemented criteriafind();
-implemented the lock()/unlock() and changed signature to synchronized ...
-added a HasSet to track the locked records, but do not track who locked
(This would require a HashMap to store additional the callee reference)

*IDataAccess Interface
declares the business methods called by the GUI client
-getAllTitles() // returns table titles
-getOriginAirports()// returns all origin airports for search
-getDestinationAirports()// returns all destination airports for search
-book()// book a flight
-criteriaFInd()// do a search in the db
*LocalData class implements IDataAccess:
-holds one private member of Data class
-implements the methods and delegates calls to the private Data class member
-in local mode the FBNClient creates one instance of this class at startup

*RemoteData class implements Remote, Unreferenced, IDataAccess:
- is initialized with a reference of the server side data singleton
( on the server exists only one data member, which is shared )


Serverside classes:
==================
*FBNServer class
-holds one private instance of the Data class (shared by all RemoteData Connections)
-holds one private instance of the Lockmanager class (shared by all RemoteData Connections)

-holds one instance of the ConnectionFactory ( called via RMI from the FBNClient)
-starts dialog and questions where db file is and what the RMI parameters are
-registers the ConnectionFactory to the RMI registry
-presents a little GUI for Shutdown(locks complete db before shutting down)
*Connectionfactory class
-offers one method getConnection()
-is bound as the ONLY RMI Object to the RMI registry
-returns a RemoteData object, which is constructed with
a reference to the server side Data member

*Lockmanager class
The purpose of this class is to verify that only the owner who locked
also unlocks. The rest of the functionality is the same as the
locking mechanism in data class, but uses a HashMap for the key-value pair.
(key=callerID object reference used, value=record locked in db)
Question what do you think on this design ?

[Michael Morris]

Hi Dan,

*Connectionfactory class
-offers one method getConnection()
-is bound as the ONLY RMI Object to the RMI registry
-returns a RemoteData object, which is constructed with
a reference to the server side Data member

To bind this to the RMI it will need to implement an interface that contains the getConnection() method and extends Remote.

*Data class
...
-implemented the lock()/unlock() and changed signature to synchronized ...
-added a HasSet to track the locked records, but do not track who locked
(This would require a HashMap to store additional the callee reference)
*Lockmanager class
The purpose of this class is to verify that only the owner who locked
also unlocks. The rest of the functionality is the same as the
locking mechanism in data class, but uses a HashMap for the key-value pair.
(key=callerID object reference used, value=record locked in db)

I have three questions:
1.) Why do you need to do both?
2.) How do you get the clientID in the LockManager?
3.) Why do you need to synch lock and unlock in Data? Should you not instead synchronize in the LockManager instead?
I am not suggesting that your design is wrong, it just seems redundant. You can actually leave lock and unlock as no-ops in Data and just do all your locking in the LockManager if you want. That's what I did and I got perfect on locking. But it's your call and if you have good reason for doing it this way and can defend it, then go for it.
Other than taking a look at those two points, I'd say you're design was on the right track.
Hope this helps,
Michael Morris

[Dan Myers]

Hi Michael,
thanks for the reply.
1a.) Why in data class locking mechanism

I do it in the data class because the requirements say ...
...Record locking must be implemented using the methods lock() and unlock()... in data class, so i
think i have to implement it in the data class, or dont i ? When i do not implement it, i would do the whole locking
in my Lockmanager. This would be completely good enough - yes.
1b.) Why an additional lockmanager
Given, that i must implement the lock/unlock in data : because the lock mechano in data can not track who
locked a record. Scenario: thread a locks( 4) thread b unlocks(4) this is still possible when i do not change
the signature of lock/unlock(int record) in data.

I see your point , i could change the lock/unlock signature in data class to ...(Object callee, int record)
as in my LockManager and so forget the additional LockManager.
2.) Each RemoteData references the Lockmanager and calls lock/unlock when needed. In my Lockmanager
the signature would be somehting like : lock/ unlock (Object callee, int record) and simply stores the callee
reference this and its records.
3.) Why sync lock/unlock in data ?
In my Lockamanger i sync lock/unlock.
Summary:
When i would be completely free, i would not implement lock/unlock in the data class and
only implement the Lockmanager, as you have suggested.
You did not implement the lock/unlock methods in the data class, did you loose points for this ?
Thanks

[friso dejonge]

Hi,
I am not sure about the following part of your code. Obviously depending on your implementation.

*IDataAccess Interface
declares the business methods called by the GUI client
-getAllTitles() // returns table titles
-getOriginAirports() // returns all origin airports for search
-getDestinationAirports()// returns all destination airports for search
-book() // book a flight
-criteriaFInd() // do a search in the db

The getAllTitles(),GetOriginAirports(), and getdestinationAirports() are basically all the same. I assume they call the criteriaFind method with a different string parameter. This restricts your class since for every additional search e.g. getCarrier() you have to build a new method while you already have the implementation in criteriafind (as long as that is generic enough).
It may be easier to call your code like
- criteriaFind("all")
- criteriaFind("carrier")
- criteriaFind("airports")
this will make your class more flexible for future aditional searches.
regards,
friso

[Michael Morris]

Hi Dan,

I do it in the data class because the requirements say ...

I went back over the instructions and found no such requirement. The instructions say that "Record locking must be implemented using the methods public void lock(int) and public void unlock(int)", it does not say that they must be implemented in the Data class.

You did not implement the lock/unlock methods in the data class, did you loose points for this ?

No. The only point I lost on the assignment was to documentation.

I see your point , i could change the lock/unlock signature in data class to ...(Object callee, int record)
as in my LockManager and so forget the additional LockManager.

That is not my point. By all means you are better off with a LockManager. I strongly believe that as little modification as possible should be inflicted on Data and certainly not chaging signatures of existing methods. Other than fixing the depracated methods and adding some cosmetic changes to Data, I left it alone. All other functionality, I implemented outside it.
My point is use a LockManager and if you want, call it from the lock and unlock methods in Data or directy from your remote implementation. If you call it from Data, of course you'll have to have a reference to it. You can add a setLockManager method if you decide to do it that way. You will also have to figure a way to get the calling objet ID into the LockManager, if you call from Data. Without changing the lock and unlock signatures, that would almost certainly incur something like adding a synchronized setClientID to Data and then synchronizing lock and unlock in Data. Of course, why go to this much trouble if you don't have to? If you just implement locking in LockManager, life becomes simpler and to lock a record the client still calls lock(record) and is oblivious to how it is accomplished, which is another prinicipal of good OOD.

2.) Each RemoteData references the Lockmanager and calls lock/unlock when needed. In my Lockmanager
the signature would be somehting like : lock/ unlock (Object callee, int record) and simply stores the callee
reference this and its records.

That's great. You're a step ahead of most of us who start this assignment. I know that I struggled with the unique ID problem for a couple of weeks, all the while Mark was trying to convince me of its simplicity. Finally, one day a big "duh" hit me when I remembered one of the precepts of Object Orientation is object identity and all became clear.
Hope this helps,
Michael Morris
[ August 21, 2002: Message edited by: Michael Morris ]
[ August 21, 2002: Message edited by: Michael Morris ]

[Dan Myers]

Hi Michael,
thanks for your comments, they helped much ...
I read carefully again the requirements - i agree.
I think i go the way you suggested and implement the LockManager only and do not
add the locking functionality to data class.
There is no point to do that , you are rigth.. it would be redundant.
I do not need lock()/unlock in local mode, so i add it to the remote side as a separate LockManager class.
thanks, i start happy coding
Dan