Backward compatibility and migration.

Backward compatibility

OTS1.1 Clients vs OTS1.4 Servers

OTS1.1 clients can safely call methods on the objects at OTS1.4 servers provided that those server objects have ADAPTS OTS policy values in their IORs.

If the objects obtained from OTS1.4 servers have REQUIRES OTS policy values in their IORs, any invocation on those objects must happen within the scope of an active transaction. Also, if the objects obtained from OTS1.4 servers have FORBIDS OTS policy values in their IORs, any invocation on those objects must happen outside the scope of an active transaction.

OTS1.1 Servers vs OTS1.4 Clients

OTS1.4 clients can work well with OTS1.1 servers, as if they are OTS1.1 clients. However, OTS1.2 clients do not unconditionally propagate the transaction context, in contrast to the OTS1.1 clients.

In cases where call-backs are used, the call-back object that an OTS1.4 client passes to an OTS1.1 server must be of type TransactionalObject if the client wants the transaction context to be propagated with the call back from the OTS1.1 server.

Migration

This section describes migration from a traditional definition of transactional objects to one using polices.

Transactional Objects that are created using version 5.1 or earlier of VisiBroker use the definition of inheriting CosTransactions::TransactionalObject interface. In order to be able to control the transactional behavior, it is necessary to migrate to defining VisiTransact policies.

The steps are as follows:

1	Remove the TransactionalObject interface from all your idl files. Use proper OTSPolicy values to control transactional requirements for all target objects.

An unshared transaction model is not supported in this release, so only SHARED and EITHER are meaningful values of Invocation Policy. Users can choose not to set explicit values for this policy; in that case VisiTransact will set the Invocation Policy for each target object with a value of EITHER.

However, users are free to set Invocation Policy for a target object and VisiTransact will check its validity against the OTSPolicy value.

2	Use proper NonTxTargetPolicy at the client side to control invocations on non-transactional objects.

3	Use CORBA::ORB::create_policy() method to create the corresponding policies.

4	Compile the code with new VisiTransact libraries.