File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes client id generation. Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "client id generation." Watch "client id generation." New topic
Author

client id generation.

Chiru babu
Greenhorn

Joined: Jan 02, 2003
Posts: 14
Hi all,
Towards client id generation, i'm following this approach plse let me know if this is wrong or can be done in a better way.
On server side i have a counter variable, and
in my client program i have a clientId(int) variable,
on client side on receiving the remote server reference, i get the value of the counter from the server and assign it to the clientId.
is this approach ok.
babu
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
It probably means that you will have to modify the signature of some of the methods supplied (lock and unlock, at least). Plenty of others before you have done this, argued in their design documentation why this must be so, and passed.
- Peter
Chiru babu
Greenhorn

Joined: Jan 02, 2003
Posts: 14
Originally posted by Peter den Haan:
It probably means that you will have to modify the signature of some of the methods supplied (lock and unlock, at least). Plenty of others before you have done this, argued in their design documentation why this must be so, and passed.
- Peter

any other approach by which i can escape this client Id, i didn't get any better approach to ensure that client who locks a record should only be allowed to unlock.
Thanks,
Rajesh So
Ranch Hand

Joined: Oct 08, 2002
Posts: 141
I have the locking mechanism in the Data class itself(it uses a LockManager class), which does not matter about many client's identification. What it knows is the thread which wants to modify, locks the record. After calling modify, the lock is removed. So it is not client Identification specific. Whoever wants to call the modify() , would lock and unlock.
I am using lock at only one place, that is in modify().
This is the code:

Is this approach okay?
John Smith
Ranch Hand

Joined: Oct 08, 2001
Posts: 2937

I am using lock at only one place, that is in modify().

Are you saying that you lock the record within the modify() method of Data class? If so, this is a bit eccentric, to say the least.
Eugene.
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
Originally posted by Chiru babu:
any other approach by which i can escape this client Id, i didn't get any better approach to ensure that client who locks a record should only be allowed to unlock.
Search for the word "connection" in this forum and you'll get more hints than a dog has fleas. No matter how filthy the dog is
- Peter
Rajesh So
Ranch Hand

Joined: Oct 08, 2002
Posts: 141
Are you saying that you lock the record within the modify() method of Data class? If so, this is a bit eccentric, to say the least.

Eugene,
My idea was to give the responsibilty of locking to the Data class. Its primary tasks are to Add/Delete/Modify/Find for any number of multiple users of it. As part of its modifying responsibility, it is ensuring that its attribute db's record is locked-modified-unlocked. So inside, modify() , before replacing the old values with the new, it is locking the record and after finishing replacing,unlocks.
1) When this thread enters this block, no other thread can use db.
2) this thread checks if lockManager holds the record or not.
3) If yes, this thread waits: Any other thread could now use db now, till the lock for the record is released.
4) If the lockManager does not hold the record, that record is locked-modified(through writeRecord)-unlocked.
5) After unlocked, the db notifies all threads.
Please tell me if this is procedure correct.
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
Originally posted by Rajesh Rajesh:
I have the locking mechanism in the Data class itself(it uses a LockManager class), which does not matter about many client's identification.
So are you implementing the semantics for unlock() as specified in the supplied javadoc?
What it knows is the thread which wants to modify, locks the record. After calling modify, the lock is removed. So it is not client Identification specific.
Or are you using the thread as a form of client identity? Dodgy. The RMI specification explicitly gives no guarantees that subsequent method calls to one and the same object are handled by one and the same thread (even though that is how the current implementation happens to work; I should add that Max Habibi would disagree with me on this).
Whoever wants to call the modify() , would lock and unlock. [...] Is this approach okay?
No. Your locking modify() method buys you nothing above and beyond the simple method synchronization that is already present in the Data class. In particular, it does not solve the problem that locking is supposed to fix --- two clients can still engage in a race condition and double-book seats.
- Peter
Rajesh So
Ranch Hand

Joined: Oct 08, 2002
Posts: 141
Or are you using the thread as a form of client identity? Dodgy.

I am not using the thread as identity of a client. Any thread which wants to modify locks the record, works on it and unlocks. Is it still wrong?

True, this problem could come in my present implementation. How can this problem be avoided? I am lost.

Any client could make any number of reads,make updates any number of times, at any time in any order.Thank you so much Peter for this.
Is my above locking/unlocking is not suitable for these type of circumstances?
John Smith
Ranch Hand

Joined: Oct 08, 2001
Posts: 2937

So inside, modify() , before replacing the old values with the new, it is locking the record and after finishing replacing,unlocks.

Rajesh,
You are going in the wrong direction. The lock() should be called before you call modify(), and unlock() should be called after modify() returns. If you accept this (and you should), you never need to change the methods of Data class, never need to explicitely call the low-level methods, such as seek(), and never need to worry about the synchronization of methods in Data.
Eugene.
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
Lock-Read-Modify-Write-Unlock.
You first lock the record so no-one else can change it. Then you read the current number of available seats because, until you locked it, it could have changed behind your back. If the number of seats is still adequate, you deduct the seat(s) from the total and write the result back to the database. Finally, you unlock the record.
- Peter
Rajesh So
Ranch Hand

Joined: Oct 08, 2002
Posts: 141
Client ID is represented as an Integer counter assigned to a client. It uses this ID for locking and unlocking. The lock and unlock signatures are altered to take one more argument for client ID.
public void lock(int record, ClientID id) throws IOException
Having an Integer as an ID may be a security violation, as some other connected client could use the same number. To avoid this, I have come out with a class like this,

The server when assigning the ID for the client would give this object, so that client cannot modify the integer value.
Please tell me if
1)Modifying the signature of lock to take the client ID is correct.
2)Necessity of having an ClientID object( a wrapper over Integer) over an Integer object.
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
Originally posted by Rajesh Rajesh:
1)Modifying the signature of lock to take the client ID is correct.
It is a valid design choice, and won't prevent you from passing. It may not be the most elegant design, but it works.
2)Necessity of having an ClientID object( a wrapper over Integer) over an Integer object.
You can do without the Integer; all you need is a private int field and trivial implementations of equals() and hashCode()
- Peter
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: client id generation.