NX: Should I call lock method before searching records?

[Jamy Wang]

I'm doing URLyBird assignment.
My DB.java is an interface must be implemented.

public void update(int recNo, String[] data, long lockCookie) throws RecordNotFoundException, SecurityException;
public void delete(int recNo, long lockCookie) RecordNotFoundException, SecurityException;
public int[] find(String[] criteria);

Should I lock all the records before I search records? But I didn't see lockCookie parameter in find() method, not like update() and delete() method.
Could you help me?

[Jay Bromley]

Hello James,
Well, the API seems to indicate that locking is not mandatory, since the find method doesn't require a cookie. This is one of those things you've got to decide on and justify yourself.
There's a couple of issues to take into account. First, given that you don't know beforehand what records will be returned for any given search, what are you going to lock? You'd have to lock the whole database down (which I believe some here have done), and for me, the problem with this is it will reduce concurrency -- no one else can get anything done until the find completes.
Note that you also have the possiblity of doing some type of synchronization that doesn't use the lock method. For example, you could use a read/write lock and read lock the database during the find. This way, other threads could read during your find, but not write until the find is complete. I like this much better than locking the whole database because it doesn't have to bring all of the other threads to a stop. This is what I'm aiming for.
A last possibility is minimal synchronization. This is what I'm doing right now, but I've got a good feeling that I'm going to change it for what I mentioned in the last paragraph. My code is something like:

class Data...
public int[] find(String[] criteria) {
    /* Note that cache is synchronized using Collections.synchronizedMap, so      
     * the following should complete in a thread-safe manner. I use the
     * toArray method so I can avoid the ConcurrentModificationException 
     * that would occur if another thread modifies the cache while I'm 
     * iterating over the key set using an Iterator.
     */
    ArrayList matches = new ArrayList();
    Integer[] keys = (Integer[])cache.keySet().toArray(new Integer[]{});
    for (int i = 0; i < keys.length; i++) {
        /* isMatch compares the current record to the criteria. It 
         * synchronizes on each record, so we're sure the record is good
         * at least while we're checking if it matches or not. We also
         * have to handle the case where a record gets deleted after 
         * doing the snapshot above, but before read below execute -
         * we accept a RecordNotFoundException, and do nothing about it.
         */
         try {
             if (isMatch(criteria, read(keys[i].intValue())) {
                 matches.add(keys[i]);
             }
         } catch (RecordNotFoundException rnf) {
             /* We allow this to happen, someone could have deleted a record
              * after we took the key snapshot. Is this ok?
              */
         }
    }
    /* Convert the List of Integers into an array of ints. Is there an
     * easier way to do this? 
     */
    int[] theMatches = new int[matches.length];
    for (int i = 0; i < matches.length; i++) {
        theMatches[i] = ((Integer) matches.get(i)).intValue();
    }
    return theMatches;
}

The above seems to work fine, and I've been sure to document the snapshot behavior in my choices.txt.
Regards,
jb

[Jamy Wang]

Thank you, Jay.
It's a good idea to maintain read and write lock!
May I lock every record before I read it? Not lock the whole database?