19992013 Ericsson AB. All Rights Reserved. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. Installing cosTransactions 1999-04-20 ch_install.xml
Installation Process

This chapter describes how to install cosTransactions in an Erlang Environment.

Preparation

Before starting the installation process for cosTransactions, the application Orber must be running.

The cosTransactions application must be able to log progress to disk. The log files are created in the current directory as "oe_name@machine_type_timestamp". Hence, read and write rights must be granted. If the transaction completes in an orderly fashion the logfiles are removed, but not if an error, which demands human intervention, occur.

Configuration

When using the Transaction Service the cosTransactions application must be started using either cosTransactions:start() or application:start(cosTransactions).

The following application configuration parameters exist:

maxRetries - default is 40 times, i.e., if a transaction participant is unreachable the application will retry to contact it N times. Reaching the maximum is considered to be a disaster. comFailWait - default is 5000 milliseconds, i.e., before the application retries to contact unreachable transaction participants the application wait Time milliseconds.

Then the Transaction Factory must be started:

cosTransactions:start_factory() - starts and returns a reference to a factory using default configuration parameters. cosTransactions:start_factory(Options) - starts and returns a reference to a factory using given configuration parameters.

The following options exist:

{hash_max, HashValue} - This value denotes the upper bound of the hash value the Coordinator uses. Default is 1013. HashValue must be an integer. {allow_subtr, Boolean} - If set to true it is possible to create subtransactions. Default is true. {typecheck, Boolean} - If set to to true all transaction operation's arguments will be type-checked. Default is true. {tty, Boolean} - Enables or disables error printouts to the tty. If Flag is false, all text that the error logger would have sent to the terminal is discarded. If Flag is true, error messages are sent to the terminal screen. {logfile, FileName} - This function makes it possible to store all system information in FileName (string()). It can be used in combination with the tty(false) item to have a silent system, where all system information are logged to a file. As default no logfile is used. {maxRetries, Integer} - default is 40 times, i.e., if a transaction participant is unreachable the application will retry to contact it N times. Reaching the maximum is considered to be a disaster. This option overrides the application configuration parameter. {comFailWait, Integer} - default is 5000 milliseconds, i.e., before the application retries to contact unreachable transaction participants the application wait Time milliseconds. This option overrides the application configuration parameter.

The Factory is now ready to use. For a more detailed description see Examples.