Java Reference
In-Depth Information
317a List<DVD> dvds = getDVDs();
317b for (Iterator i = dvds.iterator(); i.hasNext(); ) {
317c DVD dvd = i.next();
318 Matcher m = p.matcher(dvd.toString());
319 if (m.find()) {
320 returnValue.add(dvd);
321 }
322 }
Discussion Point: Caching Records
So far we have made minor concessions to speeding up the data access code, but we still have
the situation where each DVD record is read from the physical file on disk—possibly the slow-
est operation of all. We have deliberately done this so that we have not overcomplicated this
chapter; however, it is worthwhile considering whether or not we can cache the data.
The first question we should address is whether caching the data will save us any disk
operations. If most operations on the data were writing to disk, then caching would not make
much sense, since we would have to update the cache and update the file for the majority of
operations. In fact, we might even end up with poorer performance than if we did not cache
the data at all. However, the application we are developing is likely to have a large number
of searches for matching records, and displaying of records, before one record is chosen for
updating. Therefore, the majority of operations could benefit from having the records cached.
The next issue is whether the memory requirements would preclude caching. Each DVD
record is relatively small, and it is likely that caching 1,000 DVD records would require far less
than 10 MB of RAM. Because most new computers being sold have at least 128 MB of RAM, we
should not have a problem caching our data.
Finally, we should take into account the impact this change will have on our code. If
adding any feature makes the code significantly harder to read, then we should consider
whether it is worth adding—certainly whoever maintains our code will not thank us if they
have to maintain unreadable code. However, adding a cache to the existing code is reasonably
simple; all we need is an extra map to hold the UPC keys and DVD records. Access to this
cache can be handled in the same way as we use the
recordNumbersLock
mutex for the UPC-to-
file-location map.
You should read the instructions you received from Sun carefully before deciding whether
or not to implement a cache. Check whether there are any performance requirements, or any
requirements for the simplest possible code. If there are no specific requirements, you can
make your own decision as to whether to implement a cache—just remember to document
your decision in your design choices document.
The ReservationsManager Class
The
ReservationsManager
class provides the ability to logically reserve a record so that a client
can modify it, secure in the knowledge that no other client can modify it until the logical reser-
vation is released.
To help explain the purpose of logical record locking, let's first consider a scenario where
there is no logical record locking, and two clients try to rent the only copy of a particular DVD:
