VisiTransact basics

This section introduces VisiBroker VisiTransact, a complete transaction management solution for transactions with CORBA applications over the Internet or intranets. This chapter describes the VisiTransact features and architectural components.

What is VisiTransact?

VisiTransact provides a complete solution for distributed transactional CORBA applications. Implemented on top of the VisiBroker ORB, VisiTransact simplifies the complexity of distributed transactions by providing an essential set of services: a transaction service, recovery and logging, integration with databases and legacy systems (Solaris platform only), and administration facilities.

It provides OMG OTS 1.4 compliant transaction service functionality, the VisiTransact Transaction Service. On the Solaris platform VisiTransact supplies an Integrated Transaction Service (ITS) which includes the XA Resource Director, Session Manager Configuration Server, Session Manager for Oracle9i, and a Pluggable Resource Interface for enabling Session Manager to work with the database of your choice.

Note

VisiTransact does not support any of the Micro Focus proprietary extensions. It is only compliant with OMG specification.

VisiTransact architecture

VisiTransact supplies the following components to provide a complete solution for the management of distributed transactions:

•	VisiTransact Transaction Service

•	Database integration (Solaris only)

•	VisiBroker Console

As shown in the following figure, VisiTransact provides components to be used for distributed transactional CORBA applications and is implemented on top of the VisiBroker ORB.

Figure 1

VisiTransact architecture

VisiTransact Transaction Service

The VisiTransact Transaction Service—conforming to the final OMG Transaction Service specification version 1.4 document—manages transaction completion.

VisiTransact is provided as a shared library and an executable. This flexible architecture allows you to deploy the VisiTransact Transaction Service instance as a standalone process or embed the instance in your application. You can load balance transactions by using multiple instances of the VisiTransact Transaction Service on your network.

VisiTransact relies on the osagent (SmartAgent) to start up and to ensure there is only one instance of the Transaction Service. The vshutdown utility also relies on the osagent to find the Transaction Service and shut it down.

Database integration (Solaris only)

The database integration components help you integrate transactional applications on Solaris platforms with databases and other Resource Managers. The following components are included for database integration:

•

Session Manager, XA Implementation (Oracle9i only). The Session Manager XA implementation allows an application to obtain a VisiTransact-enabled connection to an Oracle9i database. The Session Manager handles all XA calls, and enables the VisiTransact Transaction Service to coordinate transactions across Resources. The Session Manager also provides database connection pooling. Additionally, the Session Manager Configuration Server enables you to create connection profiles using the VisiBroker Console.

•

Session Manager, DirectConnect Implementation (Oracle9i only). The DirectConnect implementation of the Session Manager provides non-XA access to Resources. It consists of a single application server process that contains a Session Manager with embedded single-phase Resources. This architecture provides improved performance because it performs a single-phase commit.

•	Session Manager Configuration Server. The Session Manager Configuration Server enables you to create Session Manager connection profiles using the VisiBroker Console. For more information about the Session Manager Configuration Server, see “Session Manager Configuration Server”.

•

Pluggable Resource Interface. The Pluggable Resource Interface gives you the capability to enable Session Manager to work with the database of your choice. It is a component that implements a set of predefined interfaces to allow transactional applications to use databases other than Oracle9i as their persistent storage in transactions managed by VisiTransact. For more information about the Pluggable Resource Interface, see “Pluggable Database Resource Module for VisiTransact”.

•

XA Resource Director. The XA Resource Director manages all interactions with a particular Resource Manager that is participating in one or more transactions. It handles all transactions with a specific Resource Manager (for example an Oracle9i database) on the network. The XA Resource Director bridges the VisiTransact and X/Open transaction environments, which allows for interoperability between the VisiTransact Resource model and the X/Open Distributed Transaction Protocol (DTP) Resource Manager model. For more information about the VisiTransact Resource model, see “What is the XA Resource Director?”.

VisiBroker Console

The VisiBroker Console is a graphical tool used in managing distributed transactions over the network and configuring connection profiles for use with specific databases. It can be used to monitor and control the status and completion of transactions. Using the Console you can create Session Manager connection profiles with the Session Manager Configuration Server. For more information about the VisiTransact section of the VisiBroker Console, see “Using the VisiBroker Console”.

VisiBroker ORB

The VisiBroker ORB provides the functionality and benefits of its implementation to applications using VisiTransact for distributed transaction management. The ORB provides many features to VisiTransact applications, including: thread-pooling, multiplexed and recycled connections, load balancing, and fault tolerance. Many of these features are typically part of a transaction processing monitor.

VisiTransact uses OMG portable interceptors, a powerful feature of the VisiBroker ORB, to implement its functionality. VisiTransact users can also take advantage of interceptors to customize transactional applications.

VisiTransact features

VisiTransact manages the completion of flat transactions using a one-phase or two-phase commit protocol, as appropriate. If there is only one Resource involved with a transaction, the one-phase commit protocol will be used.

In addition to the distributed transaction management features described in CORBA's Transaction Service specification, VisiTransact provides extensions to the specification. These extensions and other features are described in the following sections.

VisiTransact CORBA compliance

VisiTransact is fully compliant with the CORBA 3.0 specification from the Object Management Group (OMG). For more details, refer to the CORBA specification located at http://www.omg.org.

VisiTransact is also compliant with the CORBAservices specification for the transaction service version 1.4 from the OMG. “VisiTransact and the CORBAservices specification” lists decisions made by VisiTransact for several options accorded by the specification.

Monitoring tools

Using the Console you can monitor and control the status and completion of transactions, as well as manage the size and location of log files.

Minimum overhead with a light footprint

Depending on your system requirements, you can have as many VisiTransact Transaction Service instances as you need on your network. The VisiTransact Transaction Service does not have to reside on every host machine in your environment.

The Session Manager (available on Solaris only) also saves system resources by pooling database connections, and reusing connections across requests.

Flexible deployments

VisiTransact optimizes deployment by providing you with three choices:

•	Linking your application/business objects in directly with the VisiTransact Transaction Service.

•	Deploying your application/business objects on the same machine with the VisiTransact Transaction Service.

•	Deploying your application/business objects on any machine regardless of the location of the VisiTransact Transaction Service.

For scalability and fault tolerance, you can deploy multiple instances of business objects and multiple instances of the VisiTransact Transaction Service on multiple machines.

On Solaris platforms, if you have a single Oracle9i database, you can achieve an even greater performance gain by linking the following into a single process:

•	Application code

•	VisiTransact Transaction Service

•	Session Manager (for Oracle9i databases on Solaris platforms only)

Support for open transaction processing standards

Currently, VisiTransact supports the OMG's CORBAservices Transaction Service and the XA protocol open transaction processing standards.

Full support for multithreading

Because VisiTransact supports multithreading, your business object can be multithreaded and, therefore, it can handle multiple requests simultaneously.

Extensions to the OMG specification

VisiTransact provides several extensions to the OMG CORBAservices specification to simplify development. For example, VisiTransact extends the current interface to provide the begin_with_name() method that allows you to assign a user-defined name to a transaction. These supplemental methods are designated in Transaction Service interfaces and classes with the icon.

VisiTransact and the CORBAservices specification

See the table below for information about how VisiTransact implements certain options of the CORBAservices specification.

Option	VisiTransact Decision
An implementation of the Transaction Service is not required to support synchronization.	VisiTransact fully supports Synchronization objects (the Synchronization interface).
The Unavailable exception is raised if the Transaction Service implementation chooses to restrict the availability of the transaction context.	VisiTransact will not raise the Unavailable exception because it does not restrict the availability of the transaction context.
An implementation of the Transaction Service is not required to initialize the transaction context of every request handler.	VisiTransact default behavior is only to initialize the transaction context if the interface supported by the target object is derived from the TransactionalObject interface. VisiTransact can be configured to initialize the transaction context of all requests. See “Creating and propagating VisiTransact-managed transactions”.
An implementation of the Transaction Service may restrict the ability for some or all of these (Coordinator, Terminator and Control) objects to be transmitted to or used in other execution environments, to enable it to guarantee transaction integrity.	VisiTransact does not impose any restrictions on the ability of the Coordinator, Terminator or Control objects to be transmitted to or used in other execution environments. See “How does the VisiTransact Transaction Service ensure completion?” for discussion of how to obtain checked behavior.
It is implementation-specific whether the Transaction Service itself monitors the participants in a transaction for failures or inactivity. Some implementations of the Transaction Service impose constraints on the use of the Transaction Service interfaces in order to guarantee integrity equivalent to that provided by the interfaces which support the X.Open DTP transaction model. This is called checked behavior.	VisiTransact does not impose constraints, but supports checked behavior in VisiTransact-managed transactions as described in “How does the VisiTransact Transaction Service ensure checked behavior?”.
Some implementations of the Transaction Service may allow transactions to be terminated by Transaction Service clients other than the one which created the transaction.	VisiTransact allows termination of a transaction by any object that uses the Terminator interface for the transaction (for example, non VisiTransact-managed transactions). However, VisiTransact restricts termination of a transaction when using the Current interface to the client thread that created the transaction.
A TransactionFactory is located using the FactoryFinder interface of the life cycle service and not by the resolve_initial_ references() operation on the ORB.	Locate a VisiTransact TransactionFactory using the VisiBroker ORB discovery facilities, such as the bind() method.
A Transaction Service implementation may optionally use the Event Service to report heuristic decisions.	VisiTransact does not use the Event Service to report heuristic decisions.
An implementation of the Transaction Service is not required to support nested transactions.	No major databases support nested transactions at this time. Therefore, VisiTransact does not support nested transactions.