Treatment of requests from Oracle Endeca Server interfaces

This topic describes how requests sent from various web services, administration URL requests, and the Bulk Load Interface are treated by the Oracle Endeca Server, in the presence of outer transactions.

Requests from the Oracle Endeca Server interfaces can be updating and non-updating (read-only).

For read-only requests, if the correct ID of the outer transaction is specified as the first element in the request, they run against the most recent version inside the outer transaction. If no transaction ID is specified, the requests run against the pre-transaction version.

For updating requests, if the correct ID is specified as the first element in the request, the requests run; otherwise, the requests wait until the outer transaction is committed (or rolled back), and are computed based on the published version of the data files that becomes available at that time.

An incorrect ID in any request results in a SOAP fault.

The following statements describe each interface in detail:

Configuration Web Service.Updating and non-updating requests are treated as updating requests. Changes to XML configuration documents made with requests from the Configuration Web Service are no different from updating requests and follow the same rules. See the section below in this topic for more information.
Entity Configuration Web Service.This Web service allows you to run both updating and non-updating requests. These requests are treated as described at the beginning of this topic.
Data Ingest Web Service. All requests from the Data Ingest Web Service are updating requests. If the correct ID is specified, the Data Ingest requests run against the most recent version available within the outer transaction; otherwise, the requests wait until the outer transaction is committed or rolled back and are computed based on the published version of the data files.
Conversation Web Service. All requests from the Conversation Web Service are non-updating. These requests are treated as described at the beginning of this topic.
Administration Web Service. Requests for taking snapshots are not allowed during outer transactions. Listing running jobs requests can be issued while an outer transaction is running. You can specify or omit the transaction ID. An incorrect transaction ID results in a SOAP fault from the Dgraph. Requests for canceling jobs can run regardless of outer transactions — they do not require specifying an outer transaction ID (they do require specifying the ID of the pending job).
Administration URL requests. The following URL administrative request must run within an outer transaction, and thus require specifying the correct transaction ID: /admin/datastore?op=updateaspell&outerTransactionId="myID"
An incorrect transaction ID results in a SOAP fault from the Dgraph. All other URL administrative requests can run alongside outer transactions regardless of whether the outer transaction ID is specified.
Bulk Load Interface. All requests from the Bulk Load Interface are updating requests. If the correct ID is specified, these requests run against the most recent version available within the outer transaction; otherwise, the requests are rejected.

Note: The Control Web Service requests do not interfere with outer transactions. In other words, requests from the Control Web Service do not require specifying an outer transaction ID regardless of whether any outer transactions are running. This is because the Control Web Service runs on the host and port of the Oracle Endeca Server, whereas all other web services run on the host and port of the Dgraph process for the data store.

Treatment of changes to the configuration documents

While an outer transaction is being processed, you can update the configuration, such as the text search configuration.

For example, any changes to the configuration of search interfaces, as well as to dimsearch_config, en_word_forms_collection, recsearch_config, relrank_strategies, stop_words, and thesaurus configuration documents are possible while an outer transaction is in progress. If the correct OuterTransactionId is specified in these requests, the requests run within a transaction; otherwise, the requests wait until the outer transaction is committed and are computed based on the post-transaction version of the data files.