12.3 LOBs in the Object Cache

When you copy one object to another in the object cache with a LOB locator attribute, only the LOB locator is copied.

This means that the LOB attribute in these two different objects contain exactly the same locator that refers to one and the same LOB value. Only when you flush the target LOB, a separate physical copy of the LOB value is made, which is distinct from the source LOB value.

See Also:

Example of Updating LOBs and Read-Consistency for a description of what version of the LOB value is seen by each object if a write operation is performed through one of the locators.

Therefore, in cases where you want to modify the LOB that was the target of the copy, you must flush the target object, refresh the target object, and then write to the LOB through the locator attribute.

Consider the following object cache issues for LOB and BFILE attributes:

• Persistent LOB attributes: Creating an object in the object cache, sets the LOB attribute to empty.

  When you create an object in the object cache that contains a persistent LOB attribute, the LOB attribute is implicitly set to empty. You may not use this empty LOB locator to write data to the LOB. You must first flush the object, thereby inserting a row into the table and creating an empty LOB, that is, a LOB with zero (0) length. Once you refresh the object in the object cache, using the OCI_PIN_LATEST function, the real LOB locator is read into the attribute, and you can then call the OCI LOB APIs to write data to the LOB.

• BFILE attributes: Creating an object in the object cache, sets the BFILE attribute to NULL.

  When creating an object with a BFILE attribute, the BFILE is set to NULL. You must update it with a valid DIRECTORY object name and file name before reading from the BFILE.