Hi, I am working on Fly by Night assignment. Spec askes me to expose all public methods of Data class to client. Due to this requirement, I think we should implement thread safe behavior such as lock/doingSomething/unlock for the database server in client side and only add book() method in client side. By doing so, the remote database server just delegates the requests to the Data class. However, spec also asked me to do the following: Because multiple concurrent connections may exist, you must make both your server and the suncertify.db classes threadsafe. Since right now, I rely on the client side to guanrantee the thread safe for database server(call lock before call database modification methods), it seems the database server itself is not thread safe, because I don't have lock/process/unlock this kind of style code inside the database server class. It sounds like there is confliction of these two requirments here. Any suggestions? Thanks a lot! Jianhua
Joined: Oct 19, 2003
Me again, let's put this in another way. Assuming I implement lock/process/unlock logic inside my remote database server class, what I should do for booking() method in client side? since in the future the database might be designed for other purpose not for travel agent, business specific methods should not reside in the server side, so I choose to implement booing() method in client side. Problem is booking method involves several database operations, lock/read/modify/write/unlock, but remote database server's modify(), and write() already contain lock/process/unlock logic, I don't want to lock twice(one is in client side, one is in server side), it's not going to work! I am really confused here! Could anybody help me out? Thanks a lot! Jianhua
Hi Jianhua, Sorry if I cannot go on with this discussion, I am still in the middle of my SCBCD study. Quicly written, I'd say that you are building a 2.5 tiers design. 2 tiers : db interface exposed to client and business methods (i.e. book()) implemented client-side 3 tiers : business methods (i.e. book()) implemented server-side and exposed to clients, while the db interface is hidden from clients. It looks like your modify() and write() methods (you wrote that they "contain lock/process/unlock") belong to a tier which shouldn't exist. In all new assignments people may choose between 2-tiers/3-tiers designs, but from memory, people who got the old FBN assignment have no choice : they *must* implement a 2-tiers one. Andrew will probably confirm this because he got FBN. So the solution of your problem is to keep locking server-side as an *fine-grained service* for the external world only but not for itself. I don't know what your write() method is, but your modify() one - as described above - should be dropped (except if your instructions require such a method of course, in which case you should implement it, but without using it). Best, Phil.
Hi Jianhua, Having your book() method on the client side does not guarantee thread safety on the server side. Your client's book() method is still going to call the server's modify() method. And since you can have two separate clients running simultaneously, that means that two separate threads can run on the server side simultaneously, both calling the modify() method. The modify() method calls seek() and then calls write() - imagine what would happen if this method was not thread safe: one thread could call seek, then the next thread could call seek, then the first thread could call write (which would overwrite the wrong record), then the other thread could call write which would also overwrite the wrong record. Now the provided Data.modify() method is already thread safe: only one thread can call it at any given time. But you have to create a couple of methods in the Data class yourself, plus you have to create a few classes for the server. You need to consider whether any of them need to be made thread safe, and what needs to happen in order to achieve that.
Problem is booking method involves several database operations, lock/read/modify/write/unlock, but remote database server's modify(), and write() already contain lock/process/unlock logic
Rewind a step. Your client is calling the server's lock(), read(), modify(), and unlock() methods. So why would your server's modify() method also call lock() and unlock()? As you yourself noted, this is going to result in locking occuring in two places, and would require some sort of reentrancy. Personally I think that your server's modify() method should just verify that the current client does own the lock on the record, and throw a DatabaseException (or a subclass of DatabaseException ) if the record is not locked. Regards, Andrew
Thank you for reply, Andrew, Philippe! Right now, I came up with a picture like this: --- server side-----
Andrew, how do you think this whole picture? it's going to work and pass the exam? Looking forward to your reply! Thanks, Jianhua [ December 04, 2003: Message edited by: Jianhua Ren ] [ December 04, 2003: Message edited by: Jianhua Ren ]
author and jackaroo
Hi Jianhua That looks better. Have you deliberately chosen the default access for those variables? Regards, Andrew
Joined: Oct 19, 2003
Thank you Andrew! I think I have to make these two static variables private. It means they can be accessed only through getter method and their value is shared among all objects of the class. Regards, Jianhua