• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

(NX,URLyBird) lock() before readRecord():

 
biang lin
Ranch Hand
Posts: 91
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Instructions says we need to lock() before updateRecord(), deleteRecord() amd createRecord().
But I think sometimes we need to lock() before readRecord().
Consider this case:
"Client1" want to book a room.
In the method book() ,we need to readRecord() by field recNo,say,"room1",to determine if "room1" has already been taken,if not ,record can be updated by updating field "owner",meaning the room has bean taken.
But if meanwhile there is another client:"client2" want to book the same room, "client2" readRecord() just after "client1" readRecord(),he can see the "room1" has not been already taken, so he can also book() this room,therefor,two clients can book the same room,this is not right.
So under this circumstance,we need to lock() the
specifed record before readRecord(),therefor the recordRecord() and updateRecord() can be done as an atomic operation and when the "client2" get the same record only after "client1" has been updated it,he will see the room has been already taken.
Am I right??
[ July 09, 2003: Message edited by: biang lin ]
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Perfectly right !
Cheers,
Phil.
 
Max Habibi
town drunk
( and author)
Sheriff
Posts: 4118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Biang,
I don't think you do need to lock before reading: after all, you have a mechanism in place to deal with the (rare) situation where two clients end up trying to book the same record at the same time: that's what you're locking code does.
The tendency to make an application 'too safe' can sometimes go too far, IMO. unsafe reads are ok, IMO: just make sure you have safe writes.
M
[ July 09, 2003: Message edited by: Max Habibi ]
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Max,
Maybe I am missing something here. What I understood from biang's message is that he intends to book a room as shown in this pseudo-code :

You wrote :

I don't tihkn you do need to lock before reading: after all, you have a mechanism in place to deal with the (rare) situation where two clients end up trying to book the same record at the same time: that's what you're locking code does.

Well, IMO, if you simplify that code (no read after lock / no test) in :

... you risks to overbook the room. Is it right or not ? If it is, I don't think that the little additional code "goes too far".
Regards,
Philippe.
 
Max Habibi
town drunk
( and author)
Sheriff
Posts: 4118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I understood him to mean reading a record, just for the sake of displaying the available options: That would be overkill. As you describe it, then yes, I agree: he does need to make sure it's bookable after he has the lock.
M
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you Max for having made that clear.
Cheers,
Phil.
 
Max Habibi
town drunk
( and author)
Sheriff
Posts: 4118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Philippe Maquet:
You wrote :


I don't tihkn you do
Philippe.

Damn new keyboard.....
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The tendency to make an application 'too safe' can sometimes go too far, IMO. unsafe reads are ok, IMO: just make sure you have safe writes.
Even for those of us who are more paranoid about dirty read , there's no need for a lock() here. Synchronizing the read() operation (along with update() and delete()) would be sufficient. Other schemes of varying complexity are possible; I won't get into them here. The word "lock" is used for both the lock() method and for synchronization, as in "acquire a lock on a monitor" - but be aware that those are not the same thing. You don't always need to lock() to obtain thread safety.
 
biang lin
Ranch Hand
Posts: 91
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Jim Yingst:
The tendency to make an application 'too safe' can sometimes go too far, IMO. unsafe reads are ok, IMO: just make sure you have safe writes.
Even for those of us who are more paranoid about dirty read , there's no need for a lock() here. Synchronizing the read() operation (along with update() and delete()) would be sufficient. Other schemes of varying complexity are possible; I won't get into them here. The word "lock" is used for both the lock() method and for synchronization, as in "acquire a lock on a monitor" - but be aware that those are not the same thing. You don't always need to lock() to obtain thread safety.

Hi Jim,
I think when booking,the method read() and update() should be done as an atomic operation,this operation should be "synchronized",that is to say,one client must acquire a lock on Data object through the "book" operation.
if there is no lock() method before this operation,maybe something will happen between read() and update().
Expecting your comment.
 
biang lin
Ranch Hand
Posts: 91
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Max Habibi:
Biang,
I don't think you do need to lock before reading: after all, you have a mechanism in place to deal with the (rare) situation where two clients end up trying to book the same record at the same time: that's what you're locking code does.
The tendency to make an application 'too safe' can sometimes go too far, IMO. unsafe reads are ok, IMO: just make sure you have safe writes.
M
[ July 09, 2003: Message edited by: Max Habibi ]


Max,
I think this is a bug if I just leave alone this (rare) situation,don't you?
 
ZhiYuan Lin
Ranch Hand
Posts: 44
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi biang
i think if lock before reading ,it just say there is one thread can reading at same time ,so for the security lost too much efficiency.
and if can change the provided interface ,then make two lock methods.1 lockForRead() 2 lockForWrite() . if a record is locked for reading,then other client still can read it.or it is locked for writing ,no other can read at the time.
but can't change the provided interface. so for the efficiency ,i choose keep the risk
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sorry, I was just talking about the situation Max was discussing in his first post - a plain read, not followed by update. There would be no need to lock this, but synchronization to prevent dirty reads might be useful. This was really a reference to past conversations with Max - sorry to intrude into this discussion. As for the case of read() before update() - I agree that lock() is necessary here, to make sure there's no change between the read() and the update().
 
biang lin
Ranch Hand
Posts: 91
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by ZhiYuan Lin:
hi biang
i think if lock before reading ,it just say there is one thread can reading at same time ,so for the security lost too much efficiency.
and if can change the provided interface ,then make two lock methods.1 lockForRead() 2 lockForWrite() . if a record is locked for reading,then other client still can read it.or it is locked for writing ,no other can read at the time.
but can't change the provided interface. so for the efficiency ,i choose keep the risk

Hi ZhiYuan ,
I mean sometimes not all the time.
Just like what Jim talk about above,a "plain read" does not need lock().
 
ZhiYuan Lin
Ranch Hand
Posts: 44
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi biang
sorry , i misunderstanded now ,i see, you mean that if client sure he want to update then locked when he read,so no other client can change the record.
but in your opinion,a "plain read" still dangerous.when a client is reading ,other client with another thread (and anoher Data object)lock and update the same record is allowed. so it is dangerous too.
just want other clients don't change the record when a client look for his data and update.
maybe to use Observer and Observable to listen to change of database is more better,i think.
but it out of require of scjd.
hi are u come from china?
 
biang lin
Ranch Hand
Posts: 91
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
ZhiYuan(林志远?? ,
I think there is only one Data object,because there is only one data resource(db file).
Therefor,"plain read" is safe.
 
ZhiYuan Lin
Ranch Hand
Posts: 44
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi biang:
sorry , i misunderstanded again,if you only one Data ,you are right ,it is safety.

i have sent a letter to you
 
biang lin
Ranch Hand
Posts: 91
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by ZhiYuan Lin:
hi biang:
sorry , i misunderstanded again,if you only one Data ,you are right ,it is safety.

i have sent a letter to you

ZhiYuan:
I have replied your mail.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic