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

Find Method

 
Jon Pengelly
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi everyone,
I have a question regarding the find method for my assignment. I synchronize the record cache in my find method so that I can process each record without having to worry about new records being added or old records being deleted.
However, my find method only returns an integer array containing the record number of the criteria-matching records. Thus, my problem is with building the return array of the record details.
This is because a thread could delete one of the matching records, or update it so that it does not match the criteria anymore. How should I build the record details list - lock the database, check that each record matches again?
Any opinions?
 
Jacques Bosch
Ranch Hand
Posts: 319
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi there.
What I did:
Build the return array of rec numbers in a synch block.
Then when reading the actual records, using the return number array, just catch and ignore any RecordNotFoundException that might occur, and move on to reading the next rec in the list.
In that way it doesn't matter to the system if a rec gets deleted after the find op.
 
Jon Pengelly
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Jacques,
Thanks for the reply.
What about the situation when a record that matched the criteria is updated so that it doesn't match the criteria any more (or is deleted and then reused) before it is read and added to the return contractor details array. This would mean that a record could be returned to the client that doesn't even match the filter criteria.
Any thoughts?
 
Lance Ewing
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I hadn't thought of that scenario yet. Good question. I think I would probably iterate through the record numbers, fetch the record details for each record number, and (as has already been mentioned) ignore any RecordNotFoundExceptions, and in addition to this check that the state still matches (by comparing the field values again). It seems like you are performing the check twice but it is possibly the only way, given the DBMain interface, to make sure that your result set still matches the criteria. This is probably the conclusion you came to, am I right?

Lance.
 
George Marinkovich
Ranch Hand
Posts: 619
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Jon,
Originally posted by Jon Pengelly:
What about the situation when a record that matched the criteria is updated so that it doesn't match the criteria any more (or is deleted and then reused) before it is read and added to the return contractor details array. This would mean that a record could be returned to the client that doesn't even match the filter criteria.

The situation you describe is possible (not terribly likely, but still possible). However, Jacques solution may solve this problem. Here's why: The Sun-supplied interface requires the find to implement a wildcard match (more specifically starts-with match). So the list of recNos returned from the Data.find method are, in fact, the candidate recNos (not the final list of matching recNos). The client needs a search facility that can provide an exact match (according to many people's interpretation of the assignment instructions). So when the list of candidate recNos is returned to the client, the client needs to filter out the records that are not exact matches. This filtering should handle the case of a record that doesn't match the search criteria any more.
Hope this helps,
George
 
Lance Ewing
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In network mode you could be looking at a filter on both the server side and client side, depending on your choices. Applying the Value Object pattern to the search feature, we would want all the data for the matching records to come back in a single call to the server, rather than all the record numbers and then separate calls to fetch each record. If your decision is to expose the full functionality (non-exact matches) of the find() method on the server, then you need a filter to filter out unmatching results prior to the server returning the results (i.e. those that have changed), and you need another filter in the client application itself that filters out those that don't exactly match (if that is your interpretation of the requirements). I guess you could have two types of search exposed on the server side, one that is exact and one that is not, and your client could call the exact one. In that case you wouldn't need the filter on the client side. There would be two types of filter on the server side.
Cheers,

Lance.
 
George Marinkovich
Ranch Hand
Posts: 619
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Lance,
I don't disagree with anything you've written. Your concern about efficiency (minimizing the network traffic between database and client) is legitimate. It's leading you toward a three-tier design (i.e., one in which you don't expose the Sun-supplied interface database operations to the client). There's nothing wrong with that, I think you can make a strong argument for doing so on efficiency grounds. Another possibile solution is a traditional two-tier design (i.e, one in which the Sun-supplied interface database operation are exposed directly to the client). The two-tier solution can work as well, although perhaps not as efficiently as the three-tier solution. I think you can do very well using either solution (even though one may be more efficient than another). You should use the one that seems best to you. If there are good reasons why you selected a particular solution you should mention them in the design choices document.
When it comes time for the examiner to assess the project, I think he gives great weight to whether the solution actually meets the requirements, then to how well it is implemented, then to how complex the solution is, then to how efficient the solution is. In other words, if you satisfy the requirements and provide a decent implementation you'll be getting most (maybe all) of the available points. I'm suggesting people worry about whether their solution works more than they worry that they have necessarily picked the best (e.g., most efficient) solution to a problem. I'm not arguing that people shouldn't pick the best solution given their understanding of the problem. I'm just saying that even if you haven't picked the optimal solution if your project satisfies the requirments and you provide a good implementation of your solution you'll do very well.
Hope this helps,
George
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic