HP Large Objects System Management Manual
HP Large Objects System Management Manual – 543599.001
4.2.5 Best Space Usage
In this algorithm, a best fit is sought for a Buddy Space that has a segment size just
smaller than the object, and a part of the object stored in that segment. This algorithm
is then repeated for the remainder of the object using decreasing segment sizes until
what is left of the object fits into the smallest segment size.
This means that the object is split up and stored in multiple Buddy Spaces, though it is
always stored within one Buddy Set.
As an example, a message of 7,358 bytes would use one segment of the 4096-byte
Buddy Space, one segment of the 2048-byte Buddy Space, one of the1024-byte
Buddy Space and the remaining 190 bytes is stored in a 512-byte segment (assuming
this Buddy Space exists). The result is that only 322 bytes of space are wasted (the
unused portion of the 512 byte segment), which is less than 5%.
As shown in this example, this algorithm means that the most space that might be
wasted is some fraction of the smallest segment size in use, which is an efficient use
of the disk space. The downside of this approach is that it does require selecting and
writing to multiple Buddy Spaces, which is less efficient for performance than the
previous approach. However, this deficiency decreases as usage concurrency of the
disk increases – that is, when there are multiple processes all accessing the same disk.
5 Considerations
5.1.1 Data Integrity
In order to ensure data integrity, it is vital to manage the Large Object system
correctly. In particular, always use the provided APIs to change the system, as they
protect against some dangerous operations. Specifically:
• Never change the extents of full BuddySpaces. If the system is filling up,
create more BuddySets using the CreateBuddySet API. If only one ‘power’ is
filling up, create additional BuddySpaces of that power by calling the
CreateBuddySpace API.
• Never purge any Large Object associated files. Use the DeleteBuddySet and
DeleteBuddySpace APIs to destroy storage. The APIs fail if the storage is in
use.
5.1.2 Coding Considerations
• It is the calling application’s responsibility to free the memory allocated by
GetBuddyObject.
• The Large Object APIs work equally well if the caller has started a
transaction, or if they have to start their own. If the APIs start the transaction,
they can cope internally with a BuddySet being full. If the API is using the
caller’s transaction, it returns with a value of 999 – Transient Error, when it
finds a given BuddySet is full for the first time. The calling application should
then retry as many times as is appropriate. A more permanent error code of
150 – No BuddySets available to store object is returned once all the
BuddySets have been marked closed.
• The Large Object API may abort the caller’s transaction. During the storage
of an object it is possible that the Large Object scheme encounters a problem
Page 30 of 37