User's Guide
Reference Manual
Release Notes
PDF
Top

cosTransactions
User's Guide
Version 1.2.9

Expand All
Contract All

Chapters

• The cosTransactions Application
  • Top of chapter
  • Content Overview
  • Brief Description of the User's Guide
• Introduction to cosTransactions
  • Top of chapter
  • Overview
• Installing cosTransactions
  • Top of chapter
  • Installation Process
• cosTransactions Examples
  • Top of chapter
  • A Tutorial on How to Create a Simple Service
• Resource Skeletons
  • Top of chapter
  • Resource Skeletons

3 Installing cosTransactions

3.1  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.