I am working on networking part of B&S assignment. According to Andrew's book, he uses RMI Connection Factory to generate different RMI client in order to have different client identification. The reason to have different client id is that client can lock and unlock a record by passing his id. However, in B&S assignment, this cookie is returned by lock method instead of providing by client. So, my question is, for B&S case, do I need to have RMI Connection Factory?
I have the same doubt. I'm working on URLybird. The lock() method returns a unique cookie value so there is no need for factory to create a new identification object for each client. But it does not hurt to use factory pattern.
Guys:- The assignment goes as follows: "If the specified record is already locked by a different client, the current thread ...". BY A DIFFERENT CLIENT. I suppose this passage means that we still need a means to identify the client before any cookies are prepared, thus the need for RMIFactory.
The exact speicification goes as follows. // Locks a record so that it can only be updated or deleted by this client. // Returned value is a cookie that must be used when the record is unlocked, // updated, or deleted. If the specified record is already locked by a different // client, the current thread gives up the CPU and consumes no CPU cycles until // the record is unlocked.
I don't think we need to identify clients as long as multiple clients are not able to lock the same record a tthe same time. [ October 14, 2008: Message edited by: Anthony Choi ]
i agree with you Anthony Choi; however my assignment is B&S and lock return cookie, and i don't implement RMI factory. i think for my implementation it is not needed as i can identify my threads and client based on the return cookie value from lock method.
also RMI factory add flexibility for future improvement you can also do the same thing with out it and decrease the number of classes needed and the simplify the process of client connection as the client will only need to lookup for one remote object and also number of stub.
Best Regards. Mohamed Darim Sulibi SCJP, SCJD in progress ....
Joined: Sep 24, 2008
Just think about a (weird?) scenario when THE SAME client tries (for some mysterious reason) to lock a record he (or she) has already locked some time before. Without client identification the lock() method would threat that call as an ordinary lock request; it would very soon discover this particular record being locked by a somebody, this leading to "give up the CPU and consumes no CPU cycles until the record is unlocked", effectively blocking the poor careless client from any other actions.
In my opinion the correct behavior would be just to ignore the erroneous request.