Just as it must do for all other client requests involving the creation, update, or deletion of data in an object store, the Object Store Service must also guarantee transactional integrity with respect to adding content. Guaranteeing the transactional integrity of content upload and storage is one of the primary functions of the Content Management Subsystem.
In order to make this guarantee, the process of adding content is divided into two stages: Stage one involves copying content into a temporary location on the server while stage two is primarily concerned with copying the content to its permanent location.
Stage one occurs within the context of a client initiated transaction involving content upload; for example, checking in a document. In this stage, the content associated with the object or objects participating in the transaction are copied from the client to a temporary location that is associated with the designated storage area in which the content will ultimately be stored. This temporary location may be a specially designated file system directory, sometimes referred to as the "inbound directory" or it may a table in the database. The type of temporary storage depends on the destination storage area type. Any metadata changes associated with the participating objects are also carried out at this during this stage.
At the conclusion of the first stage of the operation, the transaction must be committed in order to make the changes durable. Committing the transaction includes adding a message to the ContentQueue, when processed, that will result in the second stage of the operation to be executed. The fact that the transaction has been committed after stage one necessarily implies that the server guarantees that the second stage will be carried out - even in the event of server disruptions, power failures, etc.
It is important to note that after a transaction involving content upload has been committed, that is, after stage one has completed, the new content has functionally been added to the storage area; a user can retrieve (or perform any other legal operation) on the new content just like any other content in the storage area, despite the fact that it may actually still reside in the temporary storage location.
At the conclusion of stage one of the operation or at anytime during its execution, the transaction can also be aborted and, therefore, must be rolled back. Rolling back a transaction in simple terms means guaranteeing that any intermediate changes that occurred during the execution of the transaction will be undone so that the system is restored to the state that it was in prior to the transaction and guaranteeing that none of these changes will be visible to any other transaction while they are being cleaned up.
With respect to content upload there are two categories of changes that need to be undone: Metadata changes and content that has been copied to the temporary storage area. The cleanup of the former is handled by the normal transaction processing mechanisms provided by the Object Store Service but the latter is a special case and is managed by the Content Management Subsystem. The way it works is temporary content is flagged as "abandoned". While it is in this state it is invisible to clients and is effectively "not there" from the client's point of view. The Content Management Subsystem then periodically sweeps the temporary storage areas and deletes all abandoned content.
Many of the functions of the Content Management Subsystem described above are parameterized such that their behavior can be modified. This is the purpose of the ContentConfiguration interface: To expose those aspects of content operations that can be adjusted in order to optimize the performance of the Object Store Service within a given operational environment.
The following tables list the members exposed by IContentConfiguration.
Public Properties
Name | Description | |
---|---|---|
![]() | AbandonedContentCleanupInterval | The number of seconds between cleanups of the inbound directory. The inbound directory is one of the temporary locations where content is stored during the first stage of content upload. A cleanup deletes those files considered abandoned; specifically, those files that have not been committed and are not participating in an existing transaction. This property works in conjunction with the TempFileLifetime property to determine which files get deleted as part of a periodic cleanup. |
![]() | AbandonedDBContentCleanupInterval | The frequency (in seconds) with which database tables containing temporary content will be scrubbed to eliminate abandoned content. Abandoned content is content not participating in an existing transaction and not committed as part of a previous transaction. This property works in conjunction with the TempDBContentLifetime property to determine which temporary content gets deleted as part of a periodic cleanup. |
![]() | ContentQueueMaxWorkerThreads | The maximum number of worker threads that can exist simultaneously per Object Store. Content Queue Worker Threads are threads that are dedicated to the purpose of processing items from the content queue. Their primary function is to carry out the second stage of the content upload process. Worker threads process work from the ContentQueue in batches of one or more queue items. |
![]() | ContentTempDirectoryRoot | The root of the directory structure that holds temporary content. Specify a fully qualified location for the root directory local to the server, such as a mount point (/mount/root) or drive (c:\data\root), and give the server exclusive permissions to access the root directory. The server must have sufficient permissions to create subdirectories; it creates the inbound directory off of this root directory. When the value for this property is null, the server uses the FileNet working directory as the directory root for temporary content. |
![]() | DatabaseContentUploadBufferSize | Reserved for future use. |
![]() | DispatcherWaitInterval | Attention: Do not change the value of this property without guidance from a support representative. Doing so might adversely affect system performance. An interval, in seconds, between processing runs for the dispatcher; during this time, the dispatcher remains idle and waits for incoming work. The value specified by this property can represent differing wait intervals depending on the class on which the property occurs, as follows:
The interaction between the minimum and maximum intervals occurs in this manner: if in the previous processing run the dispatcher had work to perform, the duration of the subsequent wait interval that the dispatcher actually remains idle is the minimum interval; otherwise, if the dispatcher had no work to perform, the duration is the shorter of these two intervals: (a) Double the previous wait interval or (b) the maximum wait interval. As an example, assuming the minimum interval to be 35 seconds and the maximum as 120, the dispatcher remains idle for 35 seconds, detects no available work, remains idle for 70 seconds (double the previous wait interval), detects no available work, remains idle for 120 seconds (the maximum interval), detects no available work, remains idle for 120 seconds, detects incoming work and processes the work, remains idle for 35 seconds, and so on. Note that, when the minimal interval equals the maximum interval (as is always the case for the For the |
![]() | ExpiredBatchSelectionSize | Batch selection size used when updating expired requests. An item in the Content Queue is said to expire when its LeaseDuration has been exceeded. Expired items must be updated so they can be retried. Expired queue items are updated in batches, the size of which is dependent on the value of this property. |
![]() | InboundFileNameCacheMaxEntries | Maximum number of inbound file names to keep in an LRU cache (default 2K). |
![]() | InlineContentRetrievalLimit | The limit of the size for inline content retrieval. |
![]() | LeaseDuration | Attention: Do not change the value of this property without guidance from a support representative. Doing so might adversely affect system performance. The maximum interval, in seconds, allowed a worker to process a batch before the assignment of the batch to another worker. This interval ensures that any abnormal termination of the worker previously assigned to the batch does not prevent batch completion. |
![]() | MaxInMemoryQueueItems | Maximum [un-dispatched] requests allowed in the in-memory queue (to avoid throwing away batches that expire while held in-memory, this number is kept very low by default, but can be increased under certain circumstances, like content migration to a slow device). Note that this limit is not evaluated until there are at least three in-memory pending batches. |
![]() | MaxResolutionBatchSize | Maximum number of items to resolve within a batch. |
![]() | PartialResolutionChunkSize | The number of content queue items to be resolved using a single delete statement, when a batch is resolved in chunks. |
![]() | RenameFileRetryAttempts | The number of times a worker thread is to attempt renaming and moving a content file from the inbound directory to its permanent location in the storage area. Also, the number of milliseconds that the thread is to wait after each failed attempt before making another renaming attempt. If all attempts fail, the thread returns the item associated with the content file to the content queue for future processing. |
![]() | RetrievalRetryAttempts | Content retrieval retry attempts (used when attempting to locate content before roll-forward is applied). |
![]() | RollFwdBatchRetryAttempts | Roll-forward batch retry attempts (before discarding the batch). |
![]() | TempDBContentLifetime | The number of seconds temporary content can exist in the database before being considered abandoned. |
![]() | TempFileLifetime | The number of seconds that temporary files must exist in the inbound directory before they will be considered abandoned. Abandoned files get deleted as part of a periodic cleanup; for more information, see the AbandonedContentCleanupInterval property. |