HP Large Objects System Management Manual

HP Large Objects System Management Manual – 543599.001
after updating the database. In such cases, the active transaction is aborted.
When the transaction was started by the caller, the API indicates that it has
aborted the transaction by setting the parameter *pCallerTransAborted
to “1” in addition to returning a return value more indicative of the specific
problem. This flag is useful as not all error conditions cause the caller’s
transaction to be aborted.
• Whenever return code 100 – System Error is returned by an API call, the
calling application should call GetSystemErrorString to get suitable diagnostic
information.
5.1.3 Considerations for Object Storage
There are a number of features of the Large Object system that should be considered
by the caller:
• Storing or retrieving objects in user defined chunks is less efficient than
allowing the Large Object system to optimise the storage.
• An application should call OpenBuddyGroup once on start-up, and then run
continuously storing, retrieving and deleting objects for that BuddyGroup
alone.
• An instance of the Buddymon program should be running for each
BuddyGroup. The purpose of the Buddymon program is to act as a central
monitor process for each BuddyGroup. Buddymon re-opens storage which
has been marked as full by the core APIs, and marks full storage as closed so
that new processes do not attempt to use it. In a batch processing
environment, where BuddyGroups could be opened and closed, there is the
additional benefit that Buddymon keeps all the files open, making calls to
OpenBuddyGroup by other applications faster.
• The Large Object system only allows writes at even numbered byte offsets.
• An application can only efficiently store objects in a single BuddyGroup.
Therefore, if more than one BuddyGroup is required the application needs to
have some method of determining which BuddyGroup to use for creating new
objects. A solution is to have a controlling server that determines in which
group to store the object, and then passes the request on to dedicated servers
for each BuddyGroup. The controlling servers could round-robin the storage
requests, or decide the correct BuddyGroup based on application defined
criteria, for example, customer number or domain. Alternatively, a batch
program could perform all the operations for BuddyGroup A, close it, open
BuddyGroup B, and perform all the operations there. The key is not to
frequently open and close BuddyGroups.
5.1.4 Limitations
• The Large Object scheme is node specific. If an application wishes to have
multi-node Large Object storage, it is necessary to have one instance of the
Large Object system installed on each node. Performance could be adversely
affected if network transactions are required.
• The Large Object scheme allows a maximum of 99 BuddySets to be created
per BuddyGroup.
• The Large Object scheme supports segment sizes in the range power 5 (32
bytes) to power 31 (approximately 1.8 GB).
Page 31 of 37