Large object requirements
To implement the Large Object Locator, the Scheduler must be running and the database must conform to requirements. Certain limitations are inherent in using large objects with a database, because the objects themselves, except for smart large objects, are not stored in the database and are not subject to direct control by the server. Two specific areas of concern are transaction rollback and concurrency control.
Database server requirements
- Non-logged databases are not supported.
- ANSI databases are not supported.
- The Scheduler must be running.
If you attempt to create a Large Object Locator data
type or run a Large Object Locator function
in an unlogged or ANSI database, a message that DataBlade
registration failed is printed in the online message log.
If the Scheduler is not running the first time that you create a Large Object Locator data
type or run a Large Object Locator function,
a message that the data type is not found or the routine cannot be
resolved is returned.
Transaction rollback
Because large objects, other than smart large objects, are stored outside the database, any changes to them take place outside the server's control and cannot be rolled back if a transaction is aborted. For example, when you execute lld_create(), it calls an operating system routine to create the large object itself. If you roll back the transaction containing the call to lld_create(), the server has no way of deleting the object that you have just created.
Therefore, you are responsible for cleaning up any resources you have allocated if an error occurs. For example, if you create a large object and the transaction in which you create it is aborted, you should delete the object you have created. Likewise, if you have opened a large object and the transaction is aborted (or is committed), you should close the large object.
Concurrency control
Large Object Locator provides no direct way of controlling concurrent access to large objects. If you open a large object for writing, it is possible to have two separate processes or users simultaneously alter the large object. You must provide a means, such as locking a row, to guarantee that multiple users cannot access a large object simultaneously for writing.