Time T4: User 2 updates cust no of record FROM "31313131" to "32323232" and thus overrides the updates made by User 1.
before updating, you should check the availability of the records
{Lock ==> Update ==> Unlock}
Items appearing within curly and burly braces above must happen as a single unit.
.the other thread has to wait until the other thread unlocks record 3
When User 2's thread is waiting, what happens on User 2's terminal? Do you show a busy cursor, implying to User 2 that "the system is busy doing something" or do you "return" control back after "some" time to User 2 saying (s)he is free to search/book other records because record 3 has already been updated?
So, "some" here would equate to the timeout parameter in wait(long timeout). In case of wait(), the return would happen ONLY IF User 2 updates or decides not to update. The point is, whether you use wait() or wait(long timeout), control would NEVER return immediately back to User 2.
And my current thinking is "control MUST return immediately back to User 2 as soon as Thread T2 encounters the wait method"
1) Search ==> Select ==> (Click on the Book button in UI to..) Lock the Record ==> Type cust no ==> (click Confirm on UI and then ){Update ==> Unlock}
(2) Search ==> Select ==> (Click on the Book button in UI) ==> Type cust no ==> (click Confirm in UI and then) {Lock ==> Update ==> Unlock}
After User 1 locks the record, if User 2 tries to lock the record, he immediately gets an error saying record is locked and he is free to search/lock/book other records.
.he current thread gives up the CPU and consumes no CPU cycles until the record is unlocked
Roel De Nijs wrote:Glad to hear you were able to clear your doubts and solve your issues
![]()
My honeysuckle is blooming this year! Now to fertilize this tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
|