Stateless services may or may not be transactional depending on whether the service uses a transactional resource. Typically, a business process service is transactional because it interacts with transactional resources, such as a JMS message service or a database service.
For a stateless business process service, Unwired Orchestrator uses the transaction manager (TM) of the J2EE host to coordinate updates to the resources as an ACID transaction. If a stateless business process service interacts with multiple transactional resources, in general, all those resources should be XA-compliant.
The following are exceptions to this rule:
One of the transactional resources within the business process service may be non-XA compliant.
EAServer supports Last Commitment Optimization in which the last resource is committed without the need to do a preparatory step. It acts as the first phase of a two-phase commit operation.
A business process service may interact with more than one non-XA database resources.
In this case, the Autocommit property of the non-XA database service operations must be set to True, resulting in the service operation committing its update to the resource immediately after the update is complete. The commit is not coordinated with the commits of the other transactional operations.
See Developing a Database Service for more information on setting transactional/non-transactional properties for a database service.
The Autocommit option is not supported for message service operations that interact with queues; thus, the queue resources must be XA-compliant.
See Runtime Properties for Messaging Types for setting XA Support on a message service.
Send your feedback on this help topic to Sybase Tech Pubs: pubs@sybase.com