Siebel Business Process Framework: Task UI Guide > Task UI Concepts > Language Concepts for Task UI >
Task transaction allows transactions to last for arbitrarily long periods of time while maintaining good reliability, performance, and scalability characteristics. Task transaction can be short-lived, or it can last for days or even months. It might even span multiple user sessions, process boundaries, and database or application server restarts.
Task transaction is dependent on a mechanism implemented in the Siebel application server, external to the underlying relational database management system (RDBMS).
NOTE: The task transaction mechanism can be turned off at both the business component level and the task level.
The following topics describe the characteristics of task transaction:
Operations performed in the task are either committed together, or aborted. Atomicity is traditionally achieved using the transactional mechanism embedded in the RDBMS. However, that mechanism is not appropriate for task transactions because it is limited to a single database connection, which then either limits the transaction's duration, or jeopardizes the system's reliability, performance, and scalability.
A change made within a task transaction can be seen only within that task transaction until it is committed (for example, with an insert, update, or delete operation). On the other hand, a change committed outside of the task transaction is also seen within the task transaction as soon as the changed record is queried again after the external change is committed.
A set of generic tables is dedicated to storing data changes within the task transaction. The Task UI framework maps columns in the generic tables to columns in the Siebel database tables, completely hiding the complexity of the storage details from the Task UI developer.
However, the need to clean up task transaction storage after transactions are committed and aborted is not transparent to Siebel administrator. The Siebel administrator must make sure that the Task UI server component group and its component Task Log Cleanup are enabled. When enabled, this component automatically cleans up the task transaction storage as a background process.
Transparent Data Retrieval
The Task UI framework merges the data in task transaction storage with the data in Siebel database tables, with full support for data filtering (search specification). Declarative data ordering (sort specification) is fully supported only for hierarchical business components; for others, ordering functions as expected only when no data is changed within the task transaction.
Conflict Detection and Resolution
Three major types of conflicts can occur within a task transaction:
Resolution Behavior in Update and Delete Conflicts
Update and delete conflicts are detected either upon data retrieval within the task transaction, or at the commit phase. You can configure their resolution behavior by setting the On Conflict task property to one of the following values:
- Continue operation. Changes made within the task transaction overwrite changes committed outside the task transaction. This does not apply to delete conflict where the record is deleted outside of the task transaction, which always returns an error message.
- Cancel operation. An error message pops up to indicate the conflict. Data in conflicting fields within the task transaction are lost, and the end user must manually resolve field-level conflicts by reentering them.