Java Reference
In-Depth Information
/**
* Unlock the requested record. Ignored if the caller does not have
* a current lock on the requested record.
*
* @param upc The UPC of the DVD to release
*/
public void releaseDVD(String upc) throws IOException {
db.releaseDVD(upc);
}
/**
* Adds a DVD to the database or inventory.
*
* @param dvd The DVD item to add to inventory.
* @return Indicates the success/failure of the add operation.
* @throws IOException Indicates there is a problem accessing the database.
*/
public boolean addDVD(DVD dvd) throws IOException, RemoteException {
return db.addDVD(dvd);
}
}
This DVDDatabaseImpl source code is interesting since it accesses the database via a
wrapper, or an adapter, called the DvdDatabase . We could have easily placed the actual data-
base method implementations, found in the class DvdFileAccess , directly in the remote object
DvdDatabaseImpl . Or we could have extended UnicastRemoteObject on DVDFileAccess and
made that object the remote object. We chose to do it this way for the following reasons:
Adding a level of abstraction between the RMI implementation and the actual data-
base-level code makes it a clearer object-oriented design and helps to separate the RMI
details from the application logic details. We wanted to create a level of separation
from the application logic and the two networking approaches: RMI and sockets. With
the preceding design, we will be able to easily use either the socket or the RMI code
depending on our preferences. We have eliminated any dependencies between the
networking packages and the database packages. This will be clarified in the project
wrap-up in Chapter 8.
In order for our locking strategy to work properly, it is important that all database modi-
fication requests first achieve a lock prior to the modification identified with a unique
DvdDatabase object. We require a unique instance of DvdDatabase in order to have a
unique identifier for the lock method; otherwise we cannot ensure that the client who
locked a record is the same one who is modifying, deleting, or even unlocking that
same record. Once the lock is granted, the modification may safely occur. Finally we
unlock the record. Because these operations must not occur in a synchronized method
(see the “Locks” section in Chapter 4), and all of the modification methods in the data-
base must be synchronized, we must access the database by way of our adapter.
Search WWH ::




Custom Search