This week's book giveaway is in the OCMJEA forum.
We're giving away four copies of OCM Java EE 6 Enterprise Architect Exam Guide and have Paul Allen & Joseph Bambara on-line!
See this thread for details.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Database Lock Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCM Java EE 6 Enterprise Architect Exam Guide this week in the OCMJEA forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Database Lock" Watch "Database Lock" New topic
Author

Database Lock

Anurag Mishra
Ranch Hand

Joined: Sep 27, 2001
Posts: 133
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

Joined: Nov 20, 2001
Posts: 38
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

Joined: Jan 13, 2002
Posts: 1
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

Joined: Jan 07, 2002
Posts: 28
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

Joined: Feb 05, 2001
Posts: 17250
    
    6

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


Perfect World Programming, LLC - Two Laptop Bag - Tube Organizer
How to Ask Questions the Smart Way FAQ
Renzo Zanelli
Greenhorn

Joined: Dec 17, 2001
Posts: 5
.. 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

Joined: Jan 07, 2002
Posts: 28
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

Joined: Jan 15, 2002
Posts: 240
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


Never be satisfied with anything less than the best and you will surely pass the test...
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17250
    
    6

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

Joined: Jan 07, 2002
Posts: 28
Smart! I didn't think of that.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Database Lock