• 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

DB and Record lock can be fool proof?

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

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
Posts: 80
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
No one try to reassure me that I do not need to develop fool proof locking?
Br,
Ban
 
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 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
Posts: 80
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
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 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
Posts: 80
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Are you tracking the client Id in your locking mechanism ?
 
Greenhorn
Posts: 18
  • 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:
[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.

 
Ranch Hand
Posts: 240
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 121
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 240
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ...
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic