This week's book giveaway is in the Performance forum.
We're giving away four copies of The Java Performance Companion and have Charlie Hunt, Monica Beckwith, Poonam Parhar, & Bengt Rutisson on-line!
See this thread for details.
Win a copy of The Java Performance Companion this week in the Performance forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Database Lock

 
Anurag Mishra
Ranch Hand
Posts: 133
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
How to handle full database lock.
My Booking Method is like this on Server:
booking(rec, tickets){
lock(rec)
modification
unlock(rec)
}
My Lock Method
public void lock(int rec)IOException{
sync(lockVector){
while(lockVector.contains(rec) || lockVector.contains(-1)){
lockVector.wait();
}catch(Except..)
lockVector.add(rec);
}
Unlock Method:-
void unlock(int rec){
sync(lockVector){
lockVector.remove(rec);
}

How to call lock method from my booking method when user enters -1 as argument. Is any modifications are required in my lock and unlock methods. Plz suggest some valid answer.
Anurag Mishra
 
amit ahuja
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
anurag,
You got to recursively check for any individual record locks and wait till all records are unlocked.
Just to mention, i don't feel anytime user will enter -1 as parameter for lock method. it's just for some future purpose. am i right??
also I wud like to know do we need read/write lock or just write lock. i mean shud we wait to lock for write if any other conection is reading?
amit
[ January 12, 2002: Message edited by: amit ahuja ]
 
Steve G
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In answer to your locking question:
Presuming that you we are working on the same assignment then it is only a 'write' lock that is required (page 5 of the submission doc).
Cheers,
Steve
 
HenkGijsbert
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
By the way Anurag,
I would advise you to use a HashMap or HashTable to store your locks, using the Thread of the caller as key and the recordNr as value (wrapped in Integer). In your sollution I can't figure out how you know WHO has locked the record. Besides it is faster.
Regards,
Henk
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
using the Thread of the caller as key

You cannot guarantee in RMI that the user will alwyas get the same Thread. Therefore you cannot use Thread of the caller as the key in RMI. You can in Object Serialization.
As far as the passing of -1 to the lock method. I would have the interface call it when it wants to close the database, when the server closes. This way all the users will be out of all their locks and it is now safe to close the database.
While I never got to see what might happen to the database if it was closed when users had locks, but for the most part I don't think it would have been pretty.
Mark
 
Renzo Zanelli
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
.. and I suggest you read Mark's words very carefully. I am talking about the lack of a guarantee that the same thread will service all requests from any single client.
Even though I had already read a similar message on the board, I spent close to an entire day trying to figure out why threads kept trying to unlock records locked by other threads. I kept assuming the problem was with clients trying to unlock records they didn't own the lock to .. until I re-read that statement very carefully, so that it would get through my thick skull. Oh well, that was experience from the school of hard knocks.
 
HenkGijsbert
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Renzo and Mark,
I also figured out that sometimes the same client get's another thread. So what I do is, having a background process on the server that checks whether threads holding a lock still are alive. If a thread is dead, the lock is removed. When the lock of a client is removed this way, the clients 'modify' call fails on a 'NoLockException' and the client tries again to lock-modify-unlock. My experience is that in less than 1% a client has to do a second attempt.
If you didn't identify clients that hold locks by threads, how does your database server then identify the clients?
(By the way, I wrote that I used 'Thread' as a key and the record number as value, but I meant the other way around.)
Regards,
Henk van Jaarsveld
 
Kalichar Rangantittu
Ranch Hand
Posts: 240
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have some refernces which I would like to share in this matter:
1. From the sun site
"In all of these cases RMI may execute in separate threads. The JavaSoft reference implementation apparently has a single thread for all references from a single client VM but this should *not* be relied upon. "
2. From jguru
Technically, you already have a pool of threads. If your Server handles ten concurrent requests, then there are ten RMI Connection Threads processing these requests. As each request finishes, the RMI Connection Threads waits for the next request "n" seconds. If the next request comes in within this window, then a waiting RMI Connection Thread handles the request. Otherwise, the RMI Run Time destroys the RMI Connection Thread and must create a new RMI Connection Thread for the next request.
As far as we know the wait time, ( "n" seconds), is part of the RMI implementation and is not alterable by developers. During heavy usage the waiting pool should suffice.
From what I see above it is extremely rare that one gets the wrong thread, possible only if one sleeps for say 20 minutes and then reinvokes a remote method.
I hear that people have tested and found that they can make it happen more often, please let me know as to how you did it. Thanks, Kalichar
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The way I handled the client ID, is simply by having a connection Remote object that each client has. When they lookup the remote object in RMIRegistry they get a connection Factory. They call the getConnection method on the Factory. This method returns the connection object. This object implements DataAccess interface and implements Remote. It also has it's own HashMap that keeps track of records it has locked. If they don't have an record ID in this HashMap for the id they are trying to unlock, it will not call the unlock in the Data Class.
Mark
 
HenkGijsbert
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Smart! I didn't think of that.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic