Locking confusion -- help

[Andy Zhu]

Hey, I got confused about the locking mechnism:

in the DBAccess, I implemented sync blocks in lock, unlock, update, and delete. all on one static map of cached records.

in the business logic (with thin client so the logic is on server), I have book and show, where book calls the sequence of DBAccess: lock -- read -- compare -- update -- unlock.

however, these operations on the business layer are not sync. So I think there is a hole between the sync operations, because even business layer called lock, it becomes unsync'ed after exiting its synchronized block. May I miss something here: should I put the book in the business to be synced?

Please help. Thanks.

[Anton Golovin]

Originally posted by Andy Zhu:
Hey, I got confused about the locking mechnism:

in the DBAccess, I implemented sync blocks in lock, unlock, update, and delete. all on one static map of cached records.

in the business logic (with thin client so the logic is on server), I have book and show, where book calls the sequence of DBAccess: lock -- read -- compare -- update -- unlock.

however, these operations on the business layer are not sync. So I think there is a hole between the sync operations, because even business layer called lock, it becomes unsync'ed after exiting its synchronized block. May I miss something here: should I put the book in the business to be synced?

Please help. Thanks.

No, because the record in question is locked and cannot be modified by any other thread.

[Andy Zhu]

Hey, Anton:

I am trying to clear my mind: in lockRecord, sync is on the map of locked record. It that recNo is already in the map, then that thread in book of business logic will go to wait for the locker. If it is not, then the thread will obtain that locker and other thread won't lock on it. Ooh, even though the lockRecord exits its sync block, the locked map already booked it and this is how it reaches atomic op in business layer. Thanks, Anton.

One more, how did you implement sync on modifiable operation at DB access: record level or database level, or simply the file pointer? I implemented on the database level, and would like to know if this will result deduction of marks.

[Anton Golovin]

Originally posted by Andy Zhu:
Hey, Anton:

I am trying to clear my mind: in lockRecord, sync is on the map of locked record. It that recNo is already in the map, then that thread in book of business logic will go to wait for the locker. If it is not, then the thread will obtain that locker and other thread won't lock on it. Ooh, even though the lockRecord exits its sync block, the locked map already booked it and this is how it reaches atomic op in business layer. Thanks, Anton.

One more, how did you implement sync on modifiable operation at DB access: record level or database level, or simply the file pointer? I implemented on the database level, and would like to know if this will result deduction of marks.

Sync on modifiable operations in data logic was by synchronizing the method itself (find, delete.) Sync on business logic (findRoom, bookRoom) was achieved via some more interesting operations. I hope they do not delete this post, and hope it is useful for you:

 public void bookRoom(final int recNo, final String[] newRoom) throws
            IOException {
 
        String[] existingRecord = null; // will store existing record recNo
 
        long cookie = 0L; // will store security value
 
        try { // locks the record in question
            cookie = data.lock(recNo);
        } catch (RecordNotFoundException rnfEx) {
            throw new IOException("Could not book record " + recNo +
                                  ". Specified record has been deleted.");
        }
 
        try { // reads in the existing record
            existingRecord = data.read(recNo);
        } catch (RecordNotFoundException rnfEx) {
            throw new IOException("Could not book record " + recNo +
                                  ". Specified record has been deleted.");
        }
 
        // these following three methods present an interesting situation.
        // if they fail to validate sameness, unbookedness and bookability of the record,
        // the bookRoom method returns. but in doing so, it leaves the
        // record being checked locked, resulting in a crushed client when a
        // client tries to act upon the record left unlocked. Thus, it is
        // necessary to unlock the record from within these methods. That
        // leaves the question of the unlock method's own exceptions in the air.
        // Here, those exceptions are irrelevant.
 
        if (!BusinessRules.areRecordsSame(newRoom, existingRecord)) {
            try { // unlocks the record
                data.unlock(recNo, cookie);
            } catch (SecurityException secEx) {
                // this will never happen because the methods are all called in order
            } catch (RecordNotFoundException rnfEx) {
                // this is irrelevant in this context, code just needs to unlock
            }
            // if record cannot be unlocked, after it was locked,
            // the only explanation is, it does not exist...
            throw new IOException("Record " + recNo +
                                  " has been deleted.");
        }
 
        // these checks are conducted if the client does not handle
        // record filtering for bookability and bookedness
 
        if (BusinessRules.BUSINESS_BOOKING_RULES_ON_SERVER) {
 
            // checks if the existing record is already booked
            if (BusinessRules.isBooked(existingRecord)) {
                try { // unlocks the record
                    data.unlock(recNo, cookie);
                } catch (SecurityException secEx) {
                    // this will never happen because the methods are all called in order
                } catch (RecordNotFoundException rnfEx) {
                    // this is irrelevant in this context, code just needs to unlock
                }
                // record is booked and cannot be booked by this method
                throw new IOException("Record " + recNo +
                                      " is already booked.");
            }
 
            // checks if existing record is bookable
            if (!BusinessRules.isBookable(existingRecord)) {
 
                try { // unlocks the record
                    data.unlock(recNo, cookie);
                } catch (SecurityException secEx) {
                    // this will never happen because the methods are all called in order
                } catch (RecordNotFoundException rnfEx) {
                    // this is irrelevant in this context, code just needs to unlock
                }
                // record does not fall within the booking rules as specified
                throw new IOException("Room at record " + recNo +
                                      " can not be booked at this time.");
            }
 
        }
 
        try { // updates the record, causing it to be booked
            data.update(recNo, newRoom, cookie);
        } catch (SecurityException secEx) {
            throw new IOException("Could not book room at record " + recNo +
                                  ". Specified room has been deleted.");
        } catch (RecordNotFoundException rnfEx) {
            throw new IOException("Could not book room at record " + recNo +
                                  ". Specified room has been deleted.");
        }
 
        try { // unlocks the record
            data.unlock(recNo, cookie);
        } catch (SecurityException secEx) {
            // this will never happen because code is called in the right order
        } catch (RecordNotFoundException rnfEx) {
            throw new IOException("Could not book room at record " + recNo +
                                  ". Specified room has been deleted.");
        }
 
        // informs of successful booking
        return;
 
    } 
 
public Map findRoom(String[] criteria) {
 
        // stores the array of record numbers which match search criteria
        final int[] recordMatches = data.find(criteria);
        // DataUtilities.log("Found " + recordMatches.length);
 
        // if none were found, returns an empty hash map
        if (recordMatches.length == 0) {
            return new HashMap(0);
        }
 
        // System.out.println("Found " + recordMatches.length + " records.");
        Map records = new HashMap(); // will store matching records
        String[] record = null; // will store a matching record for the loop
 
        // loops and finds out if a found record is furthermore bookable
        for (int i = 0; i < recordMatches.length; i++) {
 
            try { // reads one of the found records
 
                // here the read method is not used within the lock-unlock
                // block as recommended by the Data class. this is done
                // because locking and unlocking methods would not in any
                // way benefit the findRoom method. read is already synchronized,
                // so a record being read may not be concurrently modified by
                // any other thread. and no gain would be realized by
                // locking a record which is to be only read.
 
                record = data.read(recordMatches[i]);
                // accounts for multi-threadedness and checks if the record
                // still exists
            } catch (RecordNotFoundException rnfEx) {
                // log the event
                DataUtilities.log(
                        "ROOMMANAGER.findRoom: Could not read record " + i);
                continue;
            }
 
            // the following code searhes again the returned records. this
            // fulfills two goals:
            // a) the findRoom method would not otherwise guarantee that it returns
            // correct
            // matching records each time (because of multi-threading). therefore,
            // it is necessary to weed out the non-matching records which
            // periodically show up, by introducing this code.
            // The findRoom method finds record numbers first, then reads those
            // records in. There is no way around this duality which allows a
            // multi-threaded environment to possibly modify a record after it
            // has been "found" by this method, so that the find is no longer
            // a matching one to the criteria.  the record needs to be rechecked.
            // b) the client expects exact matches of its search criteria, and
            // the find method of Data class produces partial matches. so this
            // time, only
            // exact matches (of one or both parameters) are accepted.
            // thus, two logical requirements are fulfilled.
 
            if (criteria.length > record.length) { // a defective record was found
                continue; // skip this record
            }
 
            // this check is conducted if the client does not handle exact
            // matching itself
 
            if (BusinessRules.BUSINESS_MATCHING_RULES_ON_SERVER) {
 
                // if there is no exact match, skip the record, it does not match
                if (!BusinessRules.matchesExactly(criteria, record)) {
                    continue;
                }
            }
 
            // these checks are conducted if the client does not handle
            // record filtering for bookability and bookedness
 
            if (BusinessRules.BUSINESS_BOOKING_RULES_ON_SERVER) {
 
                // checks if a record is actually booked
                if (BusinessRules.isBooked(record)) {
                    continue; // record can not be returned even though it matched
                }
                // checks if a record is bookable in terms of business logic
                if (!BusinessRules.isBookable(record)) {
                    continue;
                }
            }
 
            // adds the record to the found storage
            records.put(new Integer(recordMatches[i]), record);
        }
        // returns a Map of found and bookable records to client
        return records;
 
    }
 

[Andy Zhu]

Thanks, Anton, for your posting. No, my last question is about the access level, my implementation is lock on the cached map (I think you mentioned a cache for this performance in another thread, but I take it as an object for locking mechnism). so it coms to me, if sun will like it or not, since it seems that I locked whole db for modifiable operation. I guess I may did too much. But I am not certain and want input about this.

Thank u.