On the server side I have a Connection Factory which basically gives instances of a FlightDAO object which in turn implements FBN remote interface and Unreferenced. Then I have a DataWrapper class which is a singleton and creates a data instance within itself. FlighDAO has a DataWrapper instance with it. LockManager takes care of locking and tracking clients. Lock and unlock are implemented in Data only. On the client side I have a ModeFactory wehich determines the Mode in which the app will execute. In case of RMI we get an instance from the factory. In case of standalone mode, I have created a Standalonedao WHICH extends FlightDAO thus resusing the already existing class. For client deaths etc I have implemented Unreferenced.
Also I have just a array of in in the FlightDAO where I store the records locked by a particular instance. In unreferenced I call Data unlock to unlock all owned locks. While unlocking I first check whether the record num is a part of owned locks Plsd review [ July 25, 2003: Message edited by: Akshay Sharma ]
Akshay Kumar Sharma<br />**********************<br />Good Better Best <br />Never Let it rest<br />For your good is better<br />and the better is the best
Hi Akshay I am not disagreeing with this, but just to give you something more to think about ... One topic that is often discussed here is what are potential enhancements to the system, and how should we cater for them? Making this class a Singleton ensures that there can only be one instance of the DataWrapper class, now and in the future. If a later requirement was to have a secondary table (for example, storing customer records), there would have to be some rewritting of your code to handle the extra table. Whereas if you allowed mutiple instances of the DataWrapper class to exist, but only used one instance of the DataWrapper class, then other classes could be written which could use a different instance of the DataWrapper class for a different table. You have to decide whether there is any value in catering for this future potential or not. The major argument against it is that you dont need it now, and who knows what the future requirement may be (which may require the code to be rewritten anyway). Or put another way: You Aren't Gunna Need It. Regards, Andrew