aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes DB and Record lock can be fool proof? 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 "DB and Record lock can be fool proof?" Watch "DB and Record lock can be fool proof?" New topic
Author

DB and Record lock can be fool proof?

Andras Nemeth
Ranch Hand

Joined: Jul 31, 2001
Posts: 80
Hi,
I checked my locks many times and always doubt in them a little.
Here is my logic:
<CODE>
if (recno == -1) dbLockInProgress = true;
while
(recno!=-1 && dbLockInProgress && (recno in lockHolder && holder of recno != actual connection)
| |
(recno = -1 && (lockHolder is empty | | (lockHolder size = 1 &&
(recno in lockHolder && holder of recno != actual connection)))
{
wait();
}
put recno,connection into lockHolder
</CODE>
My problem that the previous pseudo code seems to be quite complex. I can not see any place to use De Morgan laws to make it simpler.
My problem also, that if a client locked (a record or the db)
abd try to lock it again... It is solved in my condition so that it won't wait. Is that ok?
Thanks,
Ban
[This message has been edited by Andras Nemeth (edited September 10, 2001).]
Andras Nemeth
Ranch Hand

Joined: Jul 31, 2001
Posts: 80
Originally posted by Andras Nemeth:
Hi,
I checked my locks many times and always doubt in them a little.

I just forgot to write about fool proof locking.
Let's assume the following code excerpt:
1. lock(-1);
2. do sg
3. lock(1);
4. do sg else
5. unlock(-1);
In my case dead lock will be at 3. The same connection tried to lock record one which is already locked the db. I can solve it with another condition, but is it needed?
or:
1. lock(1);
2. do sg
3. lock(1);
4. do sg else
5. unlock(-1);
At 3. my code will let the lock(1) as it would lock the record 1, but is it good solution. Let's assume that 2. and 4. modify the same record. It means, that if 4 won't read the record before modification at 4. the modification at 2. will be lost.
Am I too distrustful or just implemented an inappropriate lock mechanism?
Thanks,
Ban
Andras Nemeth
Ranch Hand

Joined: Jul 31, 2001
Posts: 80
No one try to reassure me that I do not need to develop fool proof locking?
Br,
Ban
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
Originally posted by Andras Nemeth:
No one try to reassure me that I do not need to develop fool proof locking?

No, you don't - but you'll probably get better marks if you do . I can't say I could make sense of all of your code (<code>(lockHolder size = 1 && (recno in lockHolder && holder of recno != actual connection))</code> especially), it may be that I'm just missing the context.
In general, I am not happy at all with solutions that progressively acquire a database lock, or at least prevent other clients from acquiring locks when a database lock is in progress. After all, you are writing a generic database engine, and it is perfectly legal for a client to lock two records:If another client attempts to acquire a database lock right after you acquired the first lock, you have a deadlock in the case of a progressive database lock implementation.
For this reason, my database lock would simply wait until all locks on the database had gone, then lock it. In the mean time, clients can freely acquire and release locks. That way, deadlocks can be avoided, at the price of having to wait longer for a database lock - but given the likely uses for a database lock (maintenance tasks &c) that is probably acceptable.
It has the added benefit of simplifying the logic considerably. If the client owns a database lock, record lock/unlock calls can simply be ignored. If not, you wait until ((the record you need has no lock or the lock is owned by you) and there is no database lock).
- Peter
Andras Nemeth
Ranch Hand

Joined: Jul 31, 2001
Posts: 80
Hi Peter,
Thank you for this detailed answer. I see the point to make the lock also simple.
I did it and I have one problem about it:
client 1: lock(1)
client 2: lock(3)
client 2: lock(-1) (wait)
client 1: unlock(1)
deadlock??? (client 2 wait, but can not release record 3)
I might misunderstood your explanation, but should I check before db lock that all the records locked by the connection which try to get db lock? It would complicate a bit this nice locking mechanism.
I look forward to reading your opinion.
Best regards,
Ban
Originally posted by Peter den Haan:
For this reason, my database lock would simply wait until all locks on the database had gone, then lock it. In the mean time, clients can freely acquire and release locks. That way, deadlocks can be avoided, at the price of having to wait longer for a database lock - but given the likely uses for a database lock (maintenance tasks &c) that is probably acceptable.
It has the added benefit of simplifying the logic considerably. If the client owns a database lock, record lock/unlock calls can simply be ignored. If not, you wait until ((the record you need has no lock or the lock is owned by you) and there is no database lock).
- Peter[/B]

Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
Originally posted by Andras Nemeth:
client 1: lock(1)
client 2: lock(3)
client 2: lock(-1) (wait)
client 1: unlock(1)
deadlock??? (client 2 wait, but can not release record 3)
In my implementation, client 2 would wait until no locks were remaining, excepting locks it held itself. So right after unlock(1), the client 2 thread would wake up (notifyAll()) and go through the lock map looking for locks held by other clients. There would be no such locks remaining. At that moment the database lock is granted.
The fact that you can't simply wait for all record locks to disappear does complicate the logic, but only slightly. Hint: continue decomposing your logic into methods until a junior programmer needs NO comments to understand the code. To illustrate the point (maybe taking things to an extreme):Above code could reside inside a Connection inner class of DatabaseServer.
- Peter

[This message has been edited by Peter den Haan (edited September 17, 2001).]
Andras Nemeth
Ranch Hand

Joined: Jul 31, 2001
Posts: 80
Thank you Peter!
You are right that splitting up and making methods for a part of a complex expression can make it easier to understand. I will do it. Unfortunately, now I have a lot to do in my work project, so I can not finish the assignment, just now.
Take care,
Ban
Raju, Gentle
Greenhorn

Joined: Sep 06, 2001
Posts: 28
Are you tracking the client Id in your locking mechanism ?
niharika singh
Greenhorn

Joined: Sep 18, 2001
Posts: 18
Originally posted by Peter den Haan:
[B] [CODE]
public void lock(int recno) {
if (recno == DATABASE_LOCK) {
lockDatabase();
Thanks for the details. However now this has created little confusion. In my assignment I do not read any where to implement database lock. Is it a 'standard' which one needs to assume or is it specified (in some other words) in the assignment which I am overlooking.
Please clarify.
(I assume that your databse lock caters to administrator of server who may need it at the time of shutdown or maintenance).
regards.
Kalichar Rangantittu
Ranch Hand

Joined: Jan 15, 2002
Posts: 240
What gets to me in this discussion is the following:
Lets say a client A has requested a lock for a record number 5 but it goes into waiting state, as the server has a lock on the database record. Now once the server closes the connection from client A, the server itself should release the database level record. When the server releases the database level record client A's waiting thread will wake up and decide to proceed with the lock as the server has not terminated as yet.
I use a lock manager that does the locking for my Data class. Any suggestions would be appreciated greately.


Never be satisfied with anything less than the best and you will surely pass the test...
Rajesh Matti
Ranch Hand

Joined: Jan 07, 2002
Posts: 121
Let server not remove the database lock at all. Exiting itself will automatically take care of the removal. Also, even if you remove, do not notify at all, so others will just wait till the server exits.
-Rajesh
Kalichar Rangantittu
Ranch Hand

Joined: Jan 15, 2002
Posts: 240
Thanks Rajesh. I however cannot do that. You see my close() method
asks all the client to release all locks held by it. This will also
notify all other thread about it.
If I have the a clinet A waiting for a lock on record 5, and
the database while shutting down will call a close() from its connection
also which will notify all other threads about it and client A will wake
up and think it has got the lock ...
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: DB and Record lock can be fool proof?