Why need a client id when lock and unlock?

[Harry Lufei]

for a typical reservation the client will get the remoteObject call, for example, the bookSeats(recNo,seats) method on it the server will do a getRecord(recNo) do a lock on the record and modify the rec and than do a unlock. In this case you don't need to keep the track of the client by client id because all the other clients have to wait before the current client releases the rec by doing a unlock.
But i found many post here about the client id, pls clarify this
Any explanation will be appreciated.

[Paul Anilprem]

What your saying is correct only if you lock the whole database itself (all the rows) for each client request. But it's highly inefficient and if you do that you'll be in trouble because that's precisly why you are asked to implement an elaborate locking mechanism. So that multiple clients can work on independent rows. (Of course, the actual file modification is done synchronously).
In such case when one client locks row1(say) by calling remotehandle.lock(1), then second client should not be allowed to release the lock of the first client by calling release(1)!
For this you need some form of client id, to make sure that the guy unlocking a row is the same guy who locked it.
HTH,
Paul.
------------------
SCJP2 Resources, Free Question A Day, Mock Exam Results and More!
www.jdiscuss.com
Get Certified, Guaranteed!
www.enthuware.com/jqplus

Your guide to SCJD exam!
www.enthuware.com/jdevplus

[Matthew Comer]

Harry,
What you are saying is true ONLY if EVERY client calls Lock->Modify->Unlock in that order, every time. Yes, if everyone calls lock first then there is no need to keep up with client id, as only one thread will get past lock(record). HOWEVER, what if another client attempts to modify without calling lock(record)? Since you don't know which client locked the record, your write routines can't be sure that the correct client is writing the record.
Also, some operations require locking more than one row. This becomes even more complicated if you don't know which client locked what.
Truthfully though, for this assignment you can probably get by without keeping up with client on the lock. I hear that plenty of people passed doing it that way. It's your design, so do what you think is best.

[Harry Lufei]

Originally posted by Paul Anil:
What your saying is correct only if you lock the whole database itself (all the rows) for each client request

Originally posted by Matthew Comer:
Harry,
HOWEVER, what if another client attempts to modify without calling lock(record)? Since you don't know which client locked the record, your write routines can't be sure that the correct client is writing the record.

Paul and Matthew:
Thanks for your replies,
I design a method(say) bookSeat() of Remote Object,when a client want to book some seat. it will call this method:
public String bookSeat(int recNo, int seatNumber){
Lock(recNo);
modify..
Unlock(recNo);
}
So every client can call bookSeat at the same time because bookSeat is no Synchronixed. And in the Lock method:
Lock(int recNo){
Synchronized(hashmap){
search the hashmap(say) if find recNo wait();
else add recNo in hashmap;
}
}
And in the Unlock method:
Unlock(int recNo){
Synchronized(hashmap){
search the hashmap find the recNo and delete it
then notify();
}
}

Will this just lock the record not the whole database and at the same time make the clients who want to modify the same record does it in order?
Please give me some comment, thanks very much

[Shailendra Guggali]

Query of Harry Lufei :
Your method is generic way of locking - let it check if int recordNumber == -1 to lock the entire database - this can be done by using a boolean flag.
if recordNumber != -1 then it can proceed with putting record in Hashtable or checking for its existence in HT.
Reg Comments of Matthew Comer :
If some Client decides to call getRecord / modify directly, then do you propose that one checks for the clientID while invoking each method , i.e., do you pass ClientID in the getRecord / modify methods for validation???
The other reason of using the lock method with ClientID is that the unlock method can also be called by any other client directly thereby allowing all other waiting clients to start processing.
The REAL query is where do you create the client ID??? I have created it in the extension of the Data class AS That is the only place all threads have to come and it can be checked for uniqueness --- and this ClientID is passed back to the client through the server.
So creation of ClientID is the first method invoked by the client and then once this ID is with the client it can use it in any method it wants.
PLS COMMENT
shailendra

[Peter den Haan]

Keeping track of client IDs is implicit in Sun's requirements, as they demand that the lock method return immediately if the client already has the desired lock.
- Peter

[Kevin Yip]

My view is that no client id is necessary if you code in the way as Harry suggested:

public String bookSeat(int recNo, int seatNumber){
Lock(recNo);
// modify..
Unlock(recNo);
}

I don't see how other clients can do the unlock since they don't hold the lock for the record in question. They can only wait for the lock to be unlocked and released by the lock holder. Note here I've made an assumption that in the Lock(recNo) method every others have to wait for that record if somebody has been holding the lock for that record.
Say, client A has just locked the record 2.
When client B calls the Lock(recNo) method he/she has to wait until client A has done with the Unlock(recNo) method. According to the code snippet above, Client B cannot proceed to call the Unlock(recNo) method until his/her wait is over and done with the Lock(recNo) method and any changes he/she needs.
Similarly for client C, client D if they all want record 2.
I'm not saying client id is not necessary for all situations. It all depends on how you write your codes.

[Shailendra Guggali]

Kevin -- you think every other client has to follow just the same sequence of calls as you prescribe!!!
NO - they can write their code ( further enhancements ) in a way where they do not call the lock method at all -- what prevents them from calling the modify() or unlock() methods directly???
This is just the way you can call add() or delete() method if you want - but is not used in the assignment.
All things apart - Client identity has to be validated someway
as Sun has asked it to be done - where they have specifically mentioned that if an attempt is made to unlock a record that has not been locked by this connection, then no action is be taken.
Adding a ClientID seems to be the simplest way
shailendra

[Harry Lufei]

Hi All:
Thank you for your concern about this topic
Now I think that just for modifying record , we can implement without client id, but for adding and deleting record for the enhancement of this project in the future, we do need a client id mechanism.
Shailendra wrote:
-----------------------------------------------------------------
I have created it in the extension of the Data class AS That is the only place all threads have to come and it can be checked for uniqueness --- and this ClientID is passed back to the client through the server.
So creation of ClientID is the first method invoked by the client and then once this ID is with the client it can use it in any method it wants.
----------------------------------------------------------------
In the method Shailendra wrote above, Every client apply and will get a unique id assigned by server immediately after client lookup a remote object, is it right? or server just use connection id as client id?
I am still not clear about the client id implementation.

[Andras Nemeth]

Originally posted by Harry Lufei:

Paul and Matthew:
Thanks for your replies,
I design a method(say) bookSeat() of Remote Object,when a client want to book some seat. it will call this method:
public String bookSeat(int recNo, int seatNumber){
Lock(recNo);
modify..
Unlock(recNo);
}

Hello,
I can not see how can you Book without read (getRecord).
Let's say Client A read the record 2 and see there is 1 free
seat. Client B read meanwhile and happy for this 1 seat also.
Client A lock this record, modify (decrease by 1, so there is
no more free seat) and unlock... Client B awaked and wants to
book this seat... because when it read there were 1 seat
available (what is now totally out-of-date data) so lock
modify and unlock record 2. Both client managed to book this
_one_ seat.
Cheers,
Ban

[Harry Lufei]

Hi:
I mean calling the bookSeat method after readRecord, and in the modify section of bookSeat() , we can compare the number of seats avaliable with the number of seats demanded, if there is not enough seats, bookSeat() will return a message String to the client to notify.
Is this reasonable?
Harry

[Matthew Comer]

You need to read the record again AFTER you have it locked to be sure that you have clean data. If you find out at that point that there are not enough seats available, then you have to inform that user that "sorry, someone else booked the seats".
Reads without a lock are "dirty" reads. They're good for getting information, but when running a transaction (like reserving a seat) you need to do lock()-> read() -> modify() -> unlock.
Matt

[Shailendra Guggali]

hi Harry
Locking can be approached in 2 ways -
1. As soon as the Client decides to operate on a record ( say the Client doubleClicks on the record row in the the JTable) record gets locked, i.e., no one can enter it anymore.
in this approach a lock time-out facility has to be incorporated - i.e., the lock is released after some time automatically ---
THIS IS THE RIGHT WAY TO DO IT.
This is more like blocking the record till the Client decides on the seats to book.
2. The lock is implemented only for that little time when the record is actually being read /written. in this case if someone writes a millisecond before you you lose the seat.
Not the right way but is simple and is accepted for this assignment.
Just in case anyone has used the FIRST APPROACH - PLS EXPLAIN FOR OUR BENEFIT.
Thanx
Shailendra

[XJ LIN]

What is the best way to produce client ID?

[R Bischof]

I would not use an ID identifying the client.
Why not use a Session concept where each client instance has it's own remote Session object on the server?
This uniquely identifies the client and you can be notified when the client dies, etc.
And no hassles with IDs
just my 0.02 Euro

[David Mullens]

I believe that it fits within the requirements of the assignment to track the connection id. In fact, that is what my requirements doc from Sun says in the unlock section.
So, I'm keeping track of the Thread. Yes, I know (from other topics on JavaRanch) that RMI does not guarantee that it keeps the same connection for the same thread. However, I believe using the Thread is a better option than having to change the signature of the lock/unlock methods. I feel, that for this assignment, keeping track of the threads will suffice...
Dave.

[Steve Marks]

Are we allowed to change the signatures of lock/unlock?

[Kalichar Rangantittu]

I have read of people who have passed with good scores using a client id. However, you need to justify your design choices.

[David Mullens]

Steve, that is the question I have. Is it okay to change the signatures of the lock/unlock methods?
I know many on this forum have said they changed the signature and pass, but that isn't really my question. I'm sure you can pass by changing the signature, but do you loose points by changing the signature.... I'll need all the points I can get <grin> and if changing the signature means I'll have points deducted, I would much rather leave the signature alone.
I've read a post by Gregory Garrison on the forum, who passed with a perfect score on the server portion. I don't believe that he changed the signatures (I don't think he tracked a Client ID either). So, it seems, he didn't loose any points by not tracking a client ID and leaving the signature of lock/unlock the same.
I'm not saying that by changing the signatures one will loose points...I just don't know. I would think the design document and your reasons for doing it one way over the other probably plays a big part....
Dave.

[Mark Spritzler]

You don't have to change the signature, and you don't have to track a client ID. I think that is how you get a perfect score in the server, well that and a couple of other design choices.
If I was a grader, I would dock a point or two for them changing the signature.
As far as client ID, I still think you need to have some kind of mechanism to make sure that a client doesn't try to unlock a record that he does not have locked. But with a design where the client locks-modifies-unlocks in one method in that many lines, you know that those clients are always unlocking records that only they have locked.
I am talking about the hacker who connects to your server, and starts calling unlock with all the record numbers, and unlocks other clients records. Which won't hurt the database really, but maybe the client that had had the lock that then calls unlock and gets an exception, or something like that.
Mark

[Morgan Bath]

Do we have to make out assignments hacker proof and moronic programmer proof?
Seems to me the uber simple 10 line lock mechanism in Max's book is fine unless someone goes out of their way to alter your code and ignore your well documented advice.
I assume the user is an idiot, not the next programmer. If he is an idiot its the customers fault for hiring him instead of me

[Andrew Monkhouse]

Hi Morgan,

Originally posted by morgan bath:
Do we have to make out assignments hacker proof and moronic programmer proof?

I don't believe either are required.
However you would be wise to consider stopping the obvious faults that can occur. Consider a car manufacturer: they don't make it impossible to steal a car, but they do take obvious steps such as making the car lockable and requiring a key to start the car.
In the same way you may want to consider using unique unguessable numbers for your lock cookies (if you have them), and you may have to consider tracking the owner of a lock if your client can call the lock code directly. Similarly you should be considering what should happen if a user calls the update method without first calling the lock method - some interfaces even have an exception which must be thown in that case.
Regards, Andrew

[Morgan Bath]

I considering a hasLock() method called within update, delete etc. Im also considering adding Unreferenced to the remote clients for disconnected lock issues. But im not going to make sure the system is hacker proof My assignment specifies you dont even have a login function so malicious intent is an assumed non-issue.
On the point about making it idiot programmer proof though, I really think thats more about documenting and assuming you wont be replaced by a cretin. If the code is readable, sensible and above all well commented and documented I consider it programmer friendly. No matter what you do, a programmer with access to your source code can fluff even the most rigid and demanding design protocol.
In your car analogy: A car designer can only design to the best of his ability. If some wannabe mechanic decides to customise his car and it blows up because he thought it would save time to move the spark plugs into the fuel tank ... well thats just another goal for Mr Darwins theory.

[joerg joerg]

Hi David Mullen,
i think, using the thread as a client identifier
is a really bad idea.
The java documentation says, that you cannot identify RMI
connections by the thread, and you can verify it yourself
by a little bit of testing:
Just create some small client/server program
which has multiple threads on the server- and client-
sides. Then you can see, that more than one thread will
occur per connection.
(BTW: I am one of the people who changed the method signature,
and passed the exam with a fair grade. So you could guess
what i would recommend)
Regards Joerg
score