Siebel Business Process Framework: Task UI Guide > Task UI Concepts > Language Concepts for Task UI >

Task Transaction

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:

• Atomicity
• Isolation
• Transparent Storage
• Transparent Data Retrieval
• Conflict Detection and Resolution

Atomicity

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.

Isolation

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.

Transparent Storage

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:

• Duplicate conflict. Is detected by unique key violation in the RDBMS during the commit phase.

  The business component's Dup Conflict In Task user property allows you to specify the desired duplicate conflict resolution behavior by setting one of three values:

  • Resolve. The duplicate record is written with its Conflict Id field being set to the value of Id.
  • Fail. The task transaction is aborted.
  • Ignore new record. The duplicate record is skipped, but the rest of the task transaction is committed.
• Update conflict. Occurs when the same record is modified both within and outside the task transaction. Similar to ad-hoc UI, the update conflict is detected based on the Modification Id system field.
• Delete conflict. Is caused by either of the following two reasons:
  • A record is deleted within and updated outside the task transaction
  • A record is updated within and deleted outside the 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.