The content storage background task is responsible for adding document content to storage areas in response to client requests. In particular, guaranteeing the transactional integrity of content upload and storage is one of the primary functions of the background task. The background task operates within the context of server hierarchy levels and so can be tuned for the local environment in which it is running.
In stage one, the content is copied from the client to a temporary location. The type of temporary storage depends on the storage area: it might be a file system directory (known as the inbound directory), or it might be a table in the object store database.
In stage two, the IBM® FileNet® P8 object to which the content belongs is created or updated. For example, the new content for a document might be checked in. Also, changes might be made to the metadata for the object. These activities occur within a client-initiated transaction, the committal of which completes stage two. When stage two completes, the new content is functionally a part of the storage area: a user can perform any legal operation with respect to the new content, even though the content might still be in the temporary storage location. For example, as with any other content in the storage area, a user can retrieve the content.
As part of the stage two transaction, an item for the content is added to the content queue. In stage three, the item in the content queue is processed, and the content is moved to its permanent location. If the destination storage area is a database storage area, stage three is not a distinct stage: it takes place as part of the stage two transaction. For other storage area types, the server guarantees that stage three eventually completes despite any server disruptions such as power failures.
If the client fails for any reason to initiate the transaction in stage two, the transaction remains incomplete. For example, the client application might unexpectedly terminate after the successful uploading of the content in stage one. Also, at the conclusion of stage two or during its execution, the transaction might fail. A failed transaction is rolled back. Rolling back a transaction means guaranteeing that any intermediate changes that occurred during the execution of the transaction are undone: the system is restored to its state before the transaction. None of these intermediate changes are visible to other transactions while the transaction is being cleaned up.
Type of change | Activity to undo the change |
---|---|
Metadata | The cleanup of metadata changes is handled by the normal transaction rollback mechanisms. |
Copied content | The incoming content that was copied to temporary storage is flagged as abandoned. While in this state, the content is invisible to clients. The content storage background task periodically sweeps the temporary storage and deletes all abandoned content. |