Java Reference
In-Depth Information
When writing a record to file, we could write each field separately, filling with spaces if
required, or we could write the entire record in one operation.
Since a disk drive is constantly spinning when doing operations, writing field by field
would be considerably slower than writing the entire record at once. This is because the
disk would have continued spinning between each call to write the field, and there would be a
small delay while the disk heads return to the correct location for writing (such an operation
would be handled by the drive controller, but it would still slow down this operation).
Although the delays caused by writing individual fields to a file would be small, they do exist,
and they would be a bottleneck in a multiuser environment since only one user can ever be
writing to the disk at any given time. We have, therefore, decided to write the entire record
at once.
In the section describing the
persistDvd
method, we will show one method of building a
record before writing it to disk. For speed and simplicity, we have decided to build a record by
starting with a
StringBuilder
of known length, and replacing the bytes within it with the con-
tents of the DVD fields. Since we want the
StringBuilder
to be a known length and contain all
nulls before we start inserting our field data, we have created an
emptyRecordString
that can
be used in the constructor of our
StringBuilder
to quickly create a known starting point.
Since the
emptyRecordString
is a static field, it is constructed in the static initializer shown
earlier.
90 public DvdFileAccess(String suppliedDbPath)
91 throws FileNotFoundException, IOException {
92 log.entering("DvdFileAccess", "getDvdFileAccess", suppliedDbPath);
93 if (dbPath == null) {
94 database = new RandomAccessFile(
95 suppliedDbPath + File.separator + DATABASE_NAME, "rw");
96 getDvdList(true);
97 dbPath = suppliedDbPath;
98 log.fine("database opened and file location table populated");
99 } else if (dbPath != suppliedDbPath) {
100 log.warning("Only one database location can be specified. "
101 + "Current location: " + dbPath + " "
102 + "Ignoring specified path: " + suppliedDbPath);
103 }
104 log.exiting("DvdFileAccess", "DvdFileAccess");
105 }
Although the
DvdFileAccess
class is not a singleton, it does not make sense to rerun the
constructor code each time the constructor is called. Setting the
database
field is one example
of code we do not want run multiple times—the first time the constructor is called, the data-
base field will be set to the
RandomAccessFile
for our data file, and after that there is no need or
desire to reset it. As shown in line 93, we check whether the database path has already been
configured, and if so, we do not perform initialization logic a second time. However, there is a
risk that somebody may call this constructor multiple times with different paths; if they do
this, a warning message will be logged stating that the newer path is being ignored.
We as developers must always be aware of how well our code performs. While it does not
make sense to agonize over every line of code trying to make it perform better, we should
attempt to spot common areas where code may perform badly.
