• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

client id generation.

 
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
author
Posts: 3252
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 14
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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,
 
Ranch Hand
Posts: 149
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Ranch Hand
Posts: 2937
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


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
Posts: 3252
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 149
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 3252
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 149
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 2937
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


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
Posts: 3252
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 149
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 3252
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
reply
    Bookmark Topic Watch Topic
  • New Topic