Transactional Behavior

Performing methods of the WorkflowService, AdministrationService and the UserService will change the content of the audit trail database and other data sources being accessed during process execution. These changes will be applied in the context of a transaction.

Furthermore, applications (e.g. Session Bean methods) may be executed on behalf of a WorkflowService or AdministrationService. These applications may access transactional resources like databases or message queues, too.

Because transactions on multiple data sources need to be synchronized, Stardust uses EJB transaction support to perform global transactions in a two-phase-commit protocol.

Container Managed Transaction Demarcation

Transaction demarcation for the WorkflowService and the AdministrationService has to be managed by the container to provide you with the highest degree of flexibility for your application design.

Hence, these beans always have to be deployed as follows:

<session>
<ejb-name>WorkflowService</ejb-name>
...
<transaction-type>Container</transaction-type>
...
</session>

Assembly Information

Normally, each method of the Stardust services and default Message Driven Beans is thought to begin and complete a transaction and the changes in the audit trail database and the transactional resources accessed by the invoked applications will be visible for other transactions. To achieve this behavior, the deployment descriptor for the Stardust Session Beans should contain the following:

<assembly-descriptor>
<container-transaction>
<method>
<ejb-name>WorkflowService</ejb-name>
<method-name>*</method-name>
</method>
<method>
<ejb-name>UserService</ejb-name>
<method-name>*</method-name>
</method>
<method>
<ejb-name>AdministrationService</ejb-name>
<method-name>*</method-name>
</method>
<method>
<ejb-name>QueryService</ejb-name>
<method-name>*</method-name>
</method>
...
<trans-attribute>RequiresNew</trans-attribute>
</container-transaction>
</assembly-descriptor>

However, it might be desirable to perform subsequent methods of these beans in a single transaction started before a Stardust Session Bean call, because the changes should be applied as a whole or not at all. In this case, the Deployment Descriptor should be:

<assembly-descriptor>
<container-transaction>
<method>
<ejb-name>WorkflowService</ejb-name>
<method-name>*</method-name>
</method>
<method>
<ejb-name>UserService</ejb-name> <method-name>*</method-name>
</method> <method> <ejb-name>AdministrationService</ejb-name>
<method-name>*</method-name>
</method> <method> <ejb-name>QueryService</ejb-name> <method-name>*</method-name> </method> ... <trans-attribute>Required</trans-attribute> </container-transaction> </assembly-descriptor>

One of the Stardust EJBs always need the trans-attribute set to RequiresNew:

Therefore your assembly descriptor must contain the following container transaction segments:

<container-transaction>
   <method>
      <ejb-name>ForkingService</ejb-name>
      <method-name>*</method-name>
   </method>
   <trans-attribute>RequiresNew</trans-attribute>
</container-transaction>

For reference Stardust ships with default deployment descriptors reflecting a basic deployment scenario.

Deployment Hints

The following steps have to be performed for creating an application embedding Stardust functionality: