This week's book giveaways are in the Java EE and JavaScript forums.
We're giving away four copies each of The Java EE 7 Tutorial Volume 1 or Volume 2(winners choice) and jQuery UI in Action and have the authors on-line!
See this thread and this one for details.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Concurrent Access by mutiple clients Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Concurrent Access by mutiple clients" Watch "Concurrent Access by mutiple clients" New topic
Author

Concurrent Access by mutiple clients

Clivant Yeo
Ranch Hand

Joined: May 22, 2004
Posts: 124
Hi ranchers,

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.

Thanks in advance!


Clivant Yeo
My Personal Website
Steve Wang
Greenhorn

Joined: Jun 27, 2003
Posts: 18
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
Clivant Yeo
Ranch Hand

Joined: May 22, 2004
Posts: 124
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.
Hanna Habashy
Ranch Hand

Joined: Aug 20, 2003
Posts: 532
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
Guvenc Gulce
Greenhorn

Joined: May 19, 2004
Posts: 6
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 $ :-)

Guvenc
Steve Wang
Greenhorn

Joined: Jun 27, 2003
Posts: 18
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?

- Steve W.
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11432
    
  85

Hi Steve,

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.

Regards, Andrew


The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Clivant Yeo
Ranch Hand

Joined: May 22, 2004
Posts: 124
Hi Andrew,

I am implementing data caching, so about synchronizing the file pointer is going to be easy as I only will use the file pointer for updation of records. Thanks all for your help.
 
 
subject: Concurrent Access by mutiple clients