Creating a transactional object

The creation of a transactional object for C++ server and clients can be achieved in two ways: by inheriting transactional object interfaces or by direct implementation.

Inheriting transactional object interfaces

Inheritance of CosTransactions::TransactionalObject interfaces in the object interfaces defines the object to be a transactional object in the C++ server and client.

Implementing transactional object interfaces

The other way, which is compliant with the OMG OTS 1.4 specification and illustrated in the example, will allow server and clients to define their transactional object to enhance its transaction controls. With these new improvements, servers are able to force a transaction requirement upon a target object by setting appropriate policies for it. Meanwhile, clients should have to make corresponding invocations according to the target object's requirement, with some new client side policies to regulate their behaviors. Thus a strong semantic control is guaranteed.

It also provide the support for policy creation and policy check on both client and server sides. It safeguards the transactional object reference creation and transactional invocations in a distributive transaction environment.

Transactional POA policy interfaces

OTSPolicy

This policy is used to describe the shared transaction behavior of a target object. It has three possible values:

•	REQUIRES – the target object need a transaction to be present with the incoming calls.

•	FORBIDS – no transaction should be present with the invocations on the target object.

•	ADAPTS – the target object is sensitive to the presence or absence of a current transaction.

InvocationPolicy

This policy specifies what kind of transactions the target object supports. A target object can choose to supported SHARED transaction model, UNSHARED transaction model, or EITHER of them by setting the invocation policies with the corresponding values.

Note:

When defining both OTSPolicy and InvocationPolicy for a target object, not all combinations are valid. Please see the OMG OTS specification version 1.2 for detail. Any one of invalid combinations in policy creation will result in an InvalidPolicy exception.

NonTxTargetPolicy

This policy is used to PERMIT a client invocation on a non-transactional target object during an active transaction or to PREVENT the client from doing it. Any client invocation that conflicts with the policy will get an INVALID_TRANSACTION exception.

Affected Server Behaviors

A new transactional server should use OTSPolicy and InvocationPolicy (optional) to control the transactional behaviors of the objects it creates. The previously specified TransactionalObject should not be used in the new server.

To create an object with needed transactional behaviors, a server must create POAs with proper policies. A POA uses the policy values with which it is created to control the object reference creation. VisiTransact Transaction Manager will examine the validity of those policies and then do one of the following:

1	if all policies are valid, a POA with specified policies is created for object activation and reference creation;

2	if policies are invalid, an exception is raised;

3	if OTSPolicy is absent on creating a POA, VisiTransact Transaction Manager provides a default value. (FORBIDS).

In the absence of InvocationPolicy, objects thus created should be treated as if they support the InvocationPolicy of EITHER.

Affected Client Behaviors

Clients shall make invocations under circumstances conforming to the requirements of the target objects. Otherwise they will get exceptions from VisiTransact Transaction Manager.

For an object that REQUIRES transactions, a call on it must happen within the scope of an active transaction, for example, the calling thread must be associated with an active transaction.

For an object that FORBIDS transactions, a call on it must be made outside the scope of any active transaction, for example, the calling thread is associated with no transaction.

For an object that ADAPTS transactions, a call on it is allowed in either case. However, the target object will behave differently depending on whether the incoming call is associated with an active transaction or not.

During an active transaction, the client uses the NonTxTargetPolicy to manipulate calls on non-transactional objects. If a client doesn't set the policy, the default value for this is PERMIT.

Dealing with UNSHARED transactions

The support for UNSHARED transactions is not fully provided with this release because the current Visibroker has a model of Asynchronous Method Invocation called NativeMessaging that is different from OMG AMI model. So VisiTransact Transaction Manager servers and clients shouldn't directly participate in an unshared transaction.

However, the InvocationPolicy of any valid values can be created successfully for a POA at the server side irrespective of this limitation.