Since the unlock() method must only unlock a record if the original lock was created by the same client, I am thinking of changing the method signature as follows: public void lock(int record, int userId) throws IOException public void unlock(int record, int userId) Any thoughts? An alternative is to implement a fancy callback back to the client to get its client Id. I've also seen some cool code that allows the client to be identified within RMI... Anyway, passing the client id directly seems like a simple and workable solution to me... My only worry is that I would then not be implementing the method signature exactly as specified in the assignment. Vlad
I don't think that changing signature is a good idea. There are couple of other options. One is to get the ClientHostName or IP Address and identify client by that property. Another option is to create custom SOcketFactories. Making client aware of some integer id also means that your client has to be aware of an integer id assigned to it. I don't think that this is a good idea.
I have yet to think of a good solution to this problem. I believe assigning a client id and changing the signature best solution, but this goes against the requirements. I've heard of a solution using RMI, but this binds the database to the RMI server implementation. Finally, identifying clients by IP address won't work if clients are accessing the server through a proxy. So, I call into question the requirement. My assignment states: Note that the locking required is effectively a "write" lock only. If updates occur to a record that is being displayed on another client, then no change occurs at the other client. However, if two clients attempt to perform the sequence lock, read, modify, write, unlock concurrently, then both modification attempts will be handled correctly. The aim is to ensure that if two customers attempt to book a seat on the same flight concurrently, then the number of available seats is definitely reduced by two, unless there was only one seat, in which case, one customer will be advised at booking time that no more seats are available.
Based on this, I believe we can rely on the fact that the client will use the sequence lock, read, write, unlock. In this case, there is no need to track the client. Any opinions?
posted 17 years ago
This is a bit of a thorny issue. I tried to read my instructions document *really* carefully. On one hand it tells you to implement a lock(int) and an unlock(int) method. On the other hand, it does not seem to say anywhere that you can't change method signatures. I would prefer to see something that says "you will not fail just for changing the signatures of these methods," but alas that is not the case. My opinion at the moment is this: If you change the method signature, and you explain why you did it, and describe the drawbacks of some alterative courses of action, then you are showing that you at least considered the problem, and surely get some marks. I really can't think of too many reasonable and simple alternative approaches... 1) Identifying the client by the socket seems unreasonable in the RMI scenario. I'm not sure it's even that great in the serialized-object-over-socket scenario. 2) Developing a "custom socket factory" seems like too much framework-level coding. Modifying the way sockets work, eg. by identifying the client inside of some sort of custom socket class seems dangerous and also not the right place to do this... 3) Modifying the RMI stuff so it can identify the client strikes me as being better than the sockets approach above, but again seems to be just too involved and not in keeping with the admonition to keep things simple I read in my assignment 4) Calling the client back to ask it what its client id is is a possibility I am considering. It's the solution I think is most promising that does not involve changing the sigantures. My intuition at this point is that one would not automatically fail for making the decision to pass the client id in with the call to unlock and lock; the assignment does state that one is allowed some latitude... Vlad
I did the following: I provide two methods in the Data class: lock(int recNo, String sessionID) which is only used in the RMI environment where multiple clients can access the server. and lock(int recNo) for the local single user environment stuff which just calls lock(recNo, "dummy")
You have a valid method with the given signature and another one which solves your RMI problem. Haven't submitted yet, so I don't know if that way is OK for SUN... ;-) Rainer