• 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

[B&S]: findByCriteria question

 
Ranch Hand
Posts: 43
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have multiple instances of Data, and class Data implements DBAccess which is provided by Sun. My Data class contains a reference to a Singleton class, ContractorDB. ContractorDB has synchronized methods for reading and writing single records.

In my current version of findByCriteria in Data, I make no use of any locks, and I'm somewhat concerned. Right now my findByCriteria compares line by line, and if it meets the search criteria, it puts the record into the long[] array. However, while it may be reading at index n, some other thread could be modifying index n+1, possibly affecting the search.

I'm concerned because while this is not a write operation that affects the state of the database, things can occur to change the output during its duration.

What are your thoughts on this?
[ January 11, 2005: Message edited by: Vincent Hernandez ]
 
Ranch Hand
Posts: 357
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The only counter to this would IMHO be to lock the entire database against writing whilst searching. I think that would be way too constricting.

My approach is the same as yours: just loop through all records and collect those that match. At presentation time, the recors may have changed, but to the user that is not really different from the situation where (s)he would have started the search a few milliseconds later.

After having read all records as returned by the find method, I do however run another matching loop over all records, to filter out those that do not match the search criteria (although as long as "book" is the only database modifying action this would never happen, I still want to take into account that it would be possible, e.g. using a newer version of the client).

I raised the same topic last week (Thoughts on searching). The single reply I got suggested that I am probably already doing too much.

Frans.
 
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Frans Janssen:
The only counter to this would IMHO be to lock the entire database against writing whilst searching. I think that would be way too constricting.



What about the new java.util.concurrent package? It would be simple to use this:
http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/CopyOnWriteArrayList.html
 
Oh the stink of it! Smell my tiny ad!
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic