Should Data block itself when locking?

[Marcos Motta]

If I issue two consecutive lock requests for the same record, from the same connection, should the second call block?

data.lock(1);
data.lock(1); // 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.

data.lock(-1);
data.lock(1); // ok
data.lock(2); // ok
data.lock(-1); // ok
data.unlock(-1); // no locks left in the db

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.

data.lock(1);
data.lock(-1); // block

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]

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 :

    if_record_is_locked
       if_locked_by_the_caller
           return_immediately
       else
           wait_till_I_can_lock_it
    else
        i_take_the_lock

Hope that helps,
Regards,
Phil.

[Jim Yingst]

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]

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]

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]

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]

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 :

  d.lock(1)
  d.lock(1) // dont block
  ...
  d.unlock(1) // record 1 is still locked
  d.unlock(1) // unlocked

becomes :

  d.lock(1)
  d.lock(1) // dont block
  ...
  d.unlock(1) // record 1 is unlocked
  d.unlock(1) // throws SecurityException according to URLyBird 1.2.1 (or maybe nothing happens in other versions of the assignment)

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.