Java Reference
In-Depth Information
block. In particular, the following revised buffer-passing ADT does not actually
read data in the
acquireBuffer
method. Users who wish to see the old con-
tents must then issue a
readBlock
request to read the data from disk into the
buffer, and then a
getDataPointer
request to gain direct access to the buffer's
data contents.
/
**
ImprovedADTforbufferpoolsusingthebuffer-passing
style.Mostuserfunctionalityisinthebufferclass,
notthebufferpoolitself.
*
/
/
**
Asinglebufferinthebufferpool
*
/
publicinterfaceBufferADT{
/
**
Readtheassociatedblockfromdisk(ifnecessary)
andreturnapointertothedata
*
/
publicbyte[]readBlock();
/
**
Returnapointertothebuffer'sdataarray
(withoutreadingfromdisk)
*
/
publicbyte[]getDataPointer();
/
**
Flagbuffer'scontentsashavingchanged,sothat
flushingtheblockwillwriteitbacktodisk
*
/
publicvoidmarkDirty();
/
**
Releasetheblock'saccesstothisbuffer.Further
accessestothisbufferareillegal.
*
/
publicvoidreleaseBuffer();
}
/
**
Thebufferpool
*
/
publicinterfaceBufferPoolADT{
/
**
Relateablocktoabuffer,returningapointerto
abufferobject
*
/
BufferacquireBuffer(intblock);
}
Again, a mode parameter could be added to the
acquireBuffer
method,
eliminating the need for the
readBlock
and
markDirty
methods.
Clearly, the buffer-passing approach places more obligations on the user of the
buffer pool. These obligations include knowing the size of a block, not corrupting
the buffer pool's storage space, and informing the buffer pool both when a block
has been modified and when it is no longer needed. So many obligations make this
approach prone to error. An advantage is that there is no need to do an extra copy
step when getting information from the user to the buffer. If the size of the records
stored is small, this is not an important consideration. If the size of the records is
large (especially if the record size and the buffer size are the same, as typically is the
case when implementing B-trees, see Section 10.5), then this efficiency issue might
