• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Concurrent Access by mutiple clients

 
Ranch Hand
Posts: 124
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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!
 
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 124
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 532
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 18
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
author and jackaroo
Posts: 12200
280
Mac IntelliJ IDE Firefox Browser Oracle C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Clivant Yeo
Ranch Hand
Posts: 124
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic