Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Should Data block itself when locking?

 
Marcos Motta
Ranch Hand
Posts: 56
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If I issue two consecutive lock requests for the same record, from the same connection, should the second call block?

My implementation does block.
However, I made all lock requests to succeed when a connection holds a database lock. It is easy to implement.

But I realized that I introduced an inconsistency. When a connection holds a lock for one record and no one else has any locks and the connection tries to lock the database, then the database lock blocks.


I am inclined to remove the hability to allow "lock(-1); lock(1);" to make it more consistent. That would make my connections always block itself in any situation.
I would like to have your opinion on this
thanks
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Marcos,
Why not to make your lock() method reentrant ?
It's quite easy to implement and it could solve your problem. In pseudo-code it gives :

Hope that helps,
Regards,
Phil.
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In my own instructions, this behavior is unspecified. It says what must happen if a different client attempts a lock - nothing about the same client. So unless you find something in your instructions which says otherwise, I would say you can implement it either way. My own lock() method is not reentrant, as I saw no reason to make it so. A client should be written in such a way as to know whether they're already locked an object - if not, how will they know to unlock it? I prefer not to coddle sloppy client code - force the client to keep track of what it's doing.
Note that my instrcutions do not require any special database lock for lock(-1), so this may have additional consequences which I haven't thought through. As alway, read your own instructions carefully, and make a choice that makes sense to you.
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Jim,
My own lock() method is not reentrant, as I saw no reason to make it so. A client should be written in such a way as to know whether they're already locked an object

It really depends on your design. In mine, reentrance is a must. When I have to lock multiple records in a loop, I must catch a DeadlockException. When this is thrown, I know that I lost a lock (LockManager unlocked one of my locks to break the deadlock), but I have no mean to know which one I lost. But as my lock() method is reentrant, I may safely retry to acquire all the locks I need.
BTW, can you imagine the messy code we should write if Java "synchronized" mechanism were not reentrant ?
Cheers,
Philippe.
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
BTW, can you imagine the messy code we should write if Java "synchronized" mechanism were not reentrant ?
Good point. I guess without a lock(-1) requirement, the need never came up, so I never thought about it. I suppose I'll look now to see if I can make it reentrant, to facilitate future enhancements. But only if it's not too complex of course - I wouldn't dream of adding complexity, no of course not...
 
Marcos Motta
Ranch Hand
Posts: 56
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, good point Phil, but like Jim said, handle reentrant unlock might be more complex than required (for the exam)? It will require something like a "lock reference count" to
allow this:
[code]
d.lock(1)
d.lock(1) // dont block
...
d.unlock(1) // record 1 is still locked
d.unlock(1) // unlocked
[code]
How did you handled this? Did you create LockManager and Lock classes? My implementations is very simple and does not have none of this, but I think it works as expected.

thank you
[ July 11, 2003: Message edited by: Marcos Motta ]
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Marcos,
Making lock() reentrant simply means that if you call lock() multiple times on the same recNo, you get exactly the same lock as if you'd called only once. So I don't need a "lock reference count".
So the example you wrote :

becomes :

Yes, I implement a LockManager class to which Data delegates the locking, but it was quite simple too. The key point is to keep record of "who" owns the lock, I mean the thread which called the lock() method. From there, lock() reentrance becomes natural, but deadlock prevention is easy to implement too.
Regards,
Phil.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic