This week's book giveaway is in the Agile and Other Processes forum.
We're giving away four copies of The Little Book of Impediments (e-book only) and have Tom Perry on-line!
See this thread for details.
Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

lock() and unlock() methods

 
vladimir levin
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Tom Peillon
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree changing the signature would be the best solution, but the spec is quite specific about what signature to use.
Indeed it is one of the few points it is specific about.
 
Tom Peillon
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree changing the signature would be the best solution, but the spec is quite specific about what signature to use.
Indeed it is one of the few points it is specific about.
 
Aleksey Matiychenko
Ranch Hand
Posts: 178
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Matt Cannata
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
vladimir levin
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
R Bischof
Ranch Hand
Posts: 48
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic