Transactionality in View Models and Data Services

A data service deployed from a transactional view model treats its own actions and all operations performed by its inputs (database operations and other data services, for example) as a single transaction. If all the operations cannot be completed, the entire transaction is rolled back.

Sybase Data Federation supports two types of transactionality:

You cannot mix transactionality types within a transaction. If a data service is transactional, it will include in its transaction only inputs of the same transactionality type (XA or non-XA) as the data service itself. For example, if a data service is defined as an XA transaction and one of its inputs uses a non-XA connector, the data service will run correctly, but that non-XA input (and any other non-XA inputs) will not be included in the transaction. Similarly, for a non-XA transaction, any inputs that use transactional database connectors will be included in the transaction; inputs that use other connectors will still run, they just won't be included in the transaction.

Suppose you have a data service called TestDS that is configured to use XA and has as inputs another data service and a database operation. In order for all the inputs to TestDS to be included in the transaction, all of the following must also be configured to use XA, and none can be configured as non-XA:

If your TestDS data service is configured as non-XA, all of its inputs must use a single non-XA database connector. That is, any input data services and database operations must be configured to use the same database connector you specify in the transaction properties of TestDS.

For product-related issues, contact Sybase Technical Support at 1-800-8SYBASE. Send your feedback on this help topic directly to Sybase Technical Publications: pubs@sybase.com