Hi fellows, I read your threadClarification on Requirement and a confusing point is the next phrase: The client classes that deals directly with the server and/or directly with the Data object (in local mode) must have the same public methods as directed I surmise the lock/unclock methods of sun.sertify.Data must use somehow client's ID to distinguish clients and to follow the specification: If an attempt is made to unlock a record that has not been locked by this connection, then no action is be taken.
Although client may not send this ID by itself. Actually I'm gonna implement each connection in own thread and use threadID as the client unique ID. And exactly as you guys mentioned create some Adapter component that would manage connectino to the DB.This means that 'clinets' have to call lock(int recNum) without worring about ID but when sun.sertify.Data gets this call from the Adapter it's aware about client ID that the adapter sent to it. My question is if sun.sertify.Data must have lock method with such a signature : lock(int recNo, long ID) but 'client' shoud use method lock(int recNo) how they may implement the same interface if they have different methods? May be I missed something but I don't know how to fit certification's requirements. May I change the signature of lock/unlock methods? Thanks to all
I struggled with the modifying the lock / unlock issue too. But before I get to that a couple of things. You could have a different version of the program, but in mine it indicates that the client must include 1 class that implements the same public interface as the Data class. The locking and unlocking is a moot issue for me because I created a RemoteData class that extends Data. The RemoteData class has the lock and unlock methods...Data doesn't. So when the client is interacting with the Data class in local mode there is no lock / unlock method to call. I have two adapter classes (1 local, 1 remote). Both of these adapters implement an interface which has the basic functionality needed within the client application... (e.g. searching, booking, etc.) So when a user clicks on the book button...I don't want to give it all away...the Adapter classes handle the booking process appropriately within its own method. (bookFlight in Remote will call lock and unlock...bookFlight in Local will not call lock and unlock). I hope that helps some. It adds a couple more classes/interfaces, but it really helps to adhere to the requirements. As to your question about the modification of the lock and unlock methods. You are just solving it the wrong way. Think about what you need to ensure that the unlock method only unlocks records that have been locked by the appropriate client. The obvious answer is you need to identify the client...but if you think a little bit harder (or ask enough times as I did in this forum) you will come up with something like this. I have a SessionFactory that provides a SessionObject to each client. So when a client calls any methods like lock or unlock the SessionObject (which resides on the server) has an opportunity to do some checking prior to completing the clients request. I think that is all I am going to say right now. Just keep in mind that your SessionObject must be unique to each client.