lock unlock

[Cathy Young]

I have seen lots of discussion about lock and unlock on this forum, but still can not convince myself that we do need them.
My simple thought is that the lock mechanism is to prevent from multiple users accessing (especially changing) the same source at the same time. Since we can synchronize the related method and achieve this why do we still need lock () and unlock ()? What is beyond "synchronized" or it is only for some situation?

[sanjeev mehra]

hi!
i also have same thought about lock(). i have posted the same thought but unfortunatly get no response. the messag i posted was
Pls. explain locking process.
1. It is for record level locking. But when a process is syn. (syn. {read, modify, write}). Then how can multiple users perform same process for diff. records simultaneously?
2. How can I get lock on a particular record? A record is not an object.I have read, store the record no. and if someone request the same no. which is in list, asked the thread to wait().Is this the way to perform lock()?
But 1st point is not clear to me, pls. give me your time.
Thanks.
Regards,
Sanjeev.
i hope we will get very response soon.

[Michael Morris]

Hi Cathy and Sanjeev,
Look at the signature of the modify() method in the Data class. It takes a DataInfo as a parameter to (assumably) change the number of seats that are now available on that flight. So, if client A and client B both want 2 seats, then both will have the same value for the resulting number of seats (current seats - 2). Yes the method is synchronized and they will have to take their turns but instead of the having 4 fewer seats available after both modify the db there will only be 2 fewer unless somehow the clients know about each other which should not be the case.
Michael Morris

[Burk Hufnagel]

Modify isn't really the problem here.
If user A wants to reserve 2 seats on record 1 and user B wants to reserve 2 seats on record 2 then neither it's no big deal.
But if both want to reserve 2 seats on record 1 then user B must wait for user A to finish so that when modify() is called it won't go from 3 to 1 to -1.
By requiring a client to lock the record, then calling read() to make sure there's enough seats available *before* calling modify() you can prevent just such an occurrance.
Otherwise, modify() itself will have to read the record before reducing the number of seats. While it's doable, this is a problem because modify() can't know if it is being called by a client reserving seats or an administrator who has to reduce the number of seats because they're using a smaller plane.
I hope this helps,
Burk
[ March 22, 2002: Message edited by: Burk Hufnagel ]

[Michael Morris]

Hi Burk,

Modify isn't really the problem here.

How can you make this statement? If client A and client B both want to modify the same record and by coincidence have read the record at approximately the same time before either has had the oppurtunity to modify it then without a locking mechanism modify is an issue, unless you alter the way it modifies the db.
Michael Morris

[Burk Hufnagel]

Michael,
You said it yourself in the slightly snipped quote below. Modify is only an issue without a locking mechanism. That's why lock() and unlock() are there.
It's also why you can leave them empty in local mode.
Burk

Originally posted by Michael Morris:
How can you make this statement? ...then without a locking mechanism modify is an issue...
Michael Morris

[Michael Morris]

Hi Burk,
I thought that was what this thread was about. Cathy wanted to know why lock() and unlock() were necessary since all public methods that alter the db are synchronized. Maybe I misunderstood, but I took her meaning to be "Why do we need to lock a record since the methods are synchronized?" I took that to mean she thought that synchronization alone was enough to protect the db from corruption in a multi-client environment. If that was not her meaning then I apologize for the confusion.
Michael Morris

[Cathy Young]

Hi, Michael and Burk,
Thanks for your explanation and you helped a lot.
I feel you two are actually talking about the same issue. What "synchronized" does is only to make sure the operation is atomic, but does not necessarily correctly. Like the 3, 1, -1 example you gave. Is this understanding right?
BTW, Michael, you did not misunderstand me. Sorry if I did not express clearly.
Thanks for your help.
Cathy

[Laudney Ren]

Originally posted by Cathy Young:
Hi, Michael and Burk,
What "synchronized" does is only to make sure the operation is atomic, but does not necessarily correctly.
Cathy

Cathy gets it right here. "synchronized" simply means that each "read, write" is atomic, thus won't be interrupted by other concurrent requests. But, to actually make the db threadsafe, you have to make sure a "read" is before a "write" and the two as a whole must be atomic!! One simple but crude way is to queue all the requests in line. Make sure every "write" is preceded by one "read" from the same client.
Hope I've expressed clearly enough.
-- Laudney

[Michael Morris]

Bingo Laudney!
Gotta pass the ACID test, right?
A is for Atomicity
C is for Consistency
I is for Isolation
D is for Durability
Michael Morris