UrlyBird: synch'd data with HashMap

[James Kitten]

Hi everybody,

I have been following some threads for a couple of days now, and decided to test the water.

I am trying to submit my UrlyBird project in 4 weeks, because of other commitments: bad planning, I know.

Anyway, I have a question regarding the flat database file:

To provide the multi-threading aspects required by the specification, does anybody think the following approach is wrong:

1. Read the whole DB file into a HashMap at startup
2. Use the HashMap as a synchronized collection (synchronized inside the Data class)
3. Periodically, write out the HashMap back to the file as entries are updated (or server closes)

Somehow, the idea of playing around with a file for each individual update seems too much trouble.

Be harsh, I am here to learn.

But not too harsh.

[Mike Vess]

The easiest way is to play around with the database file for each client update, no need to write down cached records "periodically". Just make sure all access to the database is synchronized.

[James Kitten]

Hi Mike,

so you would just recommend using a RandomAccessFile to perform live updates to the DB file? And never bother with any in-memory collection?

JK

[Andrew Monkhouse]

Hi James,

Welcome to JavaRanch and this forum.

We don't have many rules here, but one we do have is the JavaRanch Official Policy On Displayed Names, which requires your displayed name to show both a first and a last name.

Could you please change your displayed name to meet this policy? You can change it here.

There have been quite a few candidates who have loaded the complete file into memory (usually for performance reasons), but as far as I know they have all written the data back to the file as soon as an update is received. This gives the best performance (most transactions will be reads) without risking possible data loss.

Regards, Andrew

[Anton Golovin]

Hi, James. I am one of those people who cached the entire data file. It offers the following benefits:

Fast searches

Fast reads

Contiguous writes to data file (record at a time...)

Only one read from the data file (when caching...)

This is some of the code I wrote to make sure data is synchronized between the cache and the data file. Since execution is unpredictable, the data file update must happen before the cache update. It does not carry much of a performance penalty: writes are contiguous, and cache updates are instantaneous.

 
 public synchronized void update(int recNo, String[] data, long lockCookie) throws
            RecordNotFoundException, SecurityException {
 
        // checks if record recNo exists
        if (!isRecord(recNo)) {
            throw new RecordNotFoundException("Record # " + recNo +
                                              " does not exist.");
        }
 
        // checks if update contains valid record data
        if (!header.validateRecord(recNo, data)) {
            throw new SecurityException("Can not update record " + recNo +
                                        ". Update contains corrupt data.");
        }
 
        // stores record number in storable format
        final Integer recordNumber = new Integer(recNo);
        // stores security cookie in storable format
        final Long securityValue = new Long(lockCookie);
 
        // checks if the client executing this code was the one who locked the
        // record
        if (!isLocked(recordNumber) &&
            !isLockedByCaller(recordNumber, securityValue)) {
            throw new SecurityException("Can not update record " + recNo +
                                        ". Client did not lock the record.");
        }
 
        try { // writes update to data file
            writeRecord(recNo, data);
        } catch (SecurityException secEx) {
            throw new SecurityException(secEx.getMessage());
        } catch (IOException ioEx) {
            // any io error is a data-integrity issue,
            // causing a security violation
            throw new SecurityException(ioEx.getMessage());
        }
        // updates record cache
        cached.set(recNo, data); // adds new record in its place
        // logs event
        DataUtilities.log("Data.UPDATE: Updated record " + recNo + ".");
 
    }
 

[Mike Vess]

I don�t think you have to cache for performance reasons in this assignment. I have done some performance test running my URLyBird application in local mode having a database containing about 600 records. When a do a search that matches 400 records it takes about 30ms to finish and that is fast enough. There is no requirement in the assignment about performance.

I think caching only makes it more complicated than needed but ofcourse if you never have done caching before then you could implement it in your solution just to learn how it works.

[Anton Golovin]

Originally posted by Mike Vess:
I don�t think you have to cache for performance reasons in this assignment. I have done some performance test running my URLyBird application in local mode having a database containing about 600 records. When a do a search that matches 400 records it takes about 30ms to finish and that is fast enough. There is no requirement in the assignment about performance.

I think caching only makes it more complicated than needed but ofcourse if you never have done caching before then you could implement it in your solution just to learn how it works.

I agree. Caching may be forgone, but if it is not, it allows very quick operation of the application for many thousands of records.

[Andy Zhu]

Hey, Anton:

I don't understand your code:

         if (!isLocked(recordNumber) &&
            !isLockedByCaller(recordNumber, securityValue)) {
              throw new SecurityException("Can not update record " + recNo +
                                        ". Client did not lock the record.");
        }

why do you have a security Value? I guess the cookie value will be enough to identify the client associated with the operation. Or should I worry about that sun will fake a cookie? May you explain a bit so that I won't miss something here? thank you
[ September 28, 2004: Message edited by: Andy Zhu ]

[Anton Golovin]

Oh, it is how I called the cookie in my parameter list; it's the same thing.