This week's book giveaway is in the Agile and Other Processes forum.
We're giving away four copies of The Little Book of Impediments (e-book only) and have Tom Perry on-line!
See this thread for details.
Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

still question about search method

 
Yuan Ye
Ranch Hand
Posts: 172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, guys
I have asked the question before, but I still don't know how to deal with it. In my project the find() method have this signature: int [] find(). And now I want to implement the search method by using find(). I want
a. the search result is the correct result.
b. the find() method is based on the db file.
To achieve a, I have to protect all the records of db file, so that no client touch(updata) them between the return of find and succesive read operation. Is that true?
To achieve b, I have to give up an alernative of caching all the records in the search method, since cache means can't fully utilize the find() method, which directly operated on db file.
It seams to me I have to use a method of locking of the records while doing search because of the signature of find() method. Is that some other solution? Thanks.
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
a. the search result is the correct result.
To achieve a, I have to protect all the records of db file, so that no client touch(updata) them between the return of find and succesive read operation. Is that true?

Not really, IMO. Consider - even if you lock all records during a search and get the "correct result", you're eventually going to unlock them, and pass your search results back to the user. The user will see them appear in his GUI, and may take some time to look at them before acting on them. During this time, other users may be interacting with the DB and changing the values in records. ou can't really prevent this - other users can change things while one user is looking at the screen. So there's little point in preventing changes during the search either, IMO. The only protection I require is that I don't want a record being written to while I'm reading that same record - because I don't want to display a record whose data is partly new and partly old. So I use some synchronization to ensure that no write interrupts a read. But I don't make other writes/reads wait until the complete find() method is executed, because that might take a long time, and there's little benefit since other users can change the record immediately after the find() is complete anyway.
b. the find() method is based on the db file.
All records which you find() must have been read from the DB file at some point, but it's certainly possible to cache that info and search the cache rather than reading from the file. IMO it's simplest to simply cache everything, rather than caching only some things, and performing different operations depending on whether a record is in the cache or not.
 
Yuan Ye
Ranch Hand
Posts: 172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jim, Thanks for your help.
a. the search result is the correct result.
I understand what you said I can never be able to return the really correct result even if I lock all file. However I am think if I do not lock all records, I might have to filter out some error records.
For example, if a user search for a name of "Tom", and find() method gives that record No.2 is "Tom", but meanwhile another client changed No.2 to another name "Mark" before my calling read(2). So after that my read of record No.2 will contain wrong information("Mark"), and I do not want to return such wrong record to the original user, so I have to do a creatia check in search()again? That seems rather wasting.

b. the find() method is based on the db file.
it's simplest to simply cache everything, rather than caching only some things, and performing different operations depending on whether a record is in the cache or not.

To solve the problem in a. I also want to cache all the records in some collection like Vector, but then I noticed I have to change the method of find(). Since now find() will be operated on a Vector instead of a real external file. I know it is still based on the db file, but it is
indirectly and I am worried about whether this is a bad thing to do. Since it seems to me that all the interface methods Sun give us should be operated on the real db file, not on a collection, isn't it true?

Please give me some direction. Thanks again.
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12014
220
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Peter,
Originally posted by Peter Ye:
I understand what you said I can never be able to return the really correct result even if I lock all file. However I am think if I do not lock all records, I might have to filter out some error records.
For example, if a user search for a name of "Tom", and find() method gives that record No.2 is "Tom", but meanwhile another client changed No.2 to another name "Mark" before my calling read(2). So after that my read of record No.2 will contain wrong information("Mark"), and I do not want to return such wrong record to the original user, so I have to do a creatia check in search()again? That seems rather wasting.

I think you have to validate the results at the client side anyway:
  • The alternative is for you to lock all records from the find. Now if I search for all records, then I will have locked the entire database.
  • Check your requirements - does your find() method return an exact match, or does it return all records that begin with the search criteria? Then what is your GUI's requirements - an exact match or a begin with match? I suspect that the requirements for these two applications are different which will require you to filter the returned records at the client side anyway.


  • Originally posted by Peter Ye:
    it seems to me that all the interface methods Sun give us should be operated on the real db file, not on a collection, isn't it true?

    What do your instructions say that makes you think this?
    I think the instructions typically call the Data class an "access" class (which makes me think of the Fa´┐Żade design pattern). I don't think it explictly requires the methods of the Data class work directly on the data file.
    Having said that, I am one of those who think that record caching is a great idea, but beyond the requirements
    Regards, Andrew
     
    Yuan Ye
    Ranch Hand
    Posts: 172
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi, Andrew.
    You are right, I have to filter the results at the client side anyway. So I decide not to cache the records. And I am not going to lock the whole records for the performance hits as Jim pointed out. Thanks you and Jim very much.
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic