This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
Sorry that I post so many threads in two days. It is regarding locking of the records. Let's say I have a client, A that access all the records after performing a search. All records have thus been locked by this client A. There comes client B who also do a search that should return all records, but oh gosh... all records have been locked. This poor client B can thus see no results. He will have to wait until this client A got locked off and thus all records get unlocked. My question is by implementing this way, am I wrong, or everyone else is like this. Would appreciate if there are other approaches.
Why do you want to lock all records when performing search? The only scenario that you need lock/unlock is that you want to update (i.e. write to) database.
Just my 2 cents
Joined: May 22, 2004
Well, IMO if I dun lock the records when they are being read by some other client, that client may have the tendency to change it.The client that read the record in the first place will be caught with a lost update problem when the other client change the record after the first client changes it.
One way is to lock as your read each record, then unlock it after you read it. When client A search records, a record might be being modified by client B, then client A has to wait until client B finish modifications. Client A shuold not lock all records at once, but one record at a time, read, get information, then unlock.
SCJD 1.4<br />SCJP 1.4<br />-----------------------------------<br />"With regard to excellence, it is not enough to know, but we must try to have and use it.<br />" Aristotle
I agree with Steve.. no need for lock during read.. You are getting a snapshot view when you do a search. It is possible that after you have shown your search results(even with complicated locks for each read) in the GUI, some other clients may change the records afterwards and your snapshot view will become invalid anyway.. that is why(during update) you need to lock, re-read the record and if there is no change then update the record (finally unlock) so your client will not trust the info that it has from the search results and it will double-check it ;-) should work.. ? I guess..
my 0.02 $ :-)
Joined: Jun 27, 2003
From Hanna Habashy's comments, I think that client A is allowed (and shoud be) to read any records from DB while client B has locked a record and got ready to update (write to) DB. Of course, while client B is physically updating (writing to) DB, client A needs to wait after client B finishes update(..) due to sync'ed file pointer access concern.
I implemented the same way as what Guvenc Gulce described above. When client A fills in his client ID (from your snapshot view in GUI) and book a room (in my URLybird assignment), he may not necessarily get booked since the room could get booked by someone else while client A is viewing the search result.
Do those experienced ranchers here like Andrew, Peter den Haan, or Phillippe have any smarter thoughts?
I was staying out of this as I felt that you were all going well.
You are right that anyone can come along after you have read a record and book it. So there is no advantage to locking each record before you read it - it can still be modified after you have read it. As long as you are ensuring that physical file access is synchronized (to avoid potential conflicts with where the file pointer is), you should be fine.