dev:005bas:010tdtrnconcept

DOKA - TradeDesign Transaction Concept

There are multiple common concepts used in DOKA-NG. The below is intended to provide a high level overview on them.

Passing information

The TradeDesign element SYSSTREAM is used to pass information from one to another transaction

  • The calling transaction might use SAVEDATA to store one or multiple entries
  • The launched transaction tries to load entries with LOADDATA and uses this data to initialize

The idea is to transport the currently selected user context between transactions.

E.g. in a fee condition display transaction the currently selected fee and the associated party (assuming it is a party condition) can be passed to the following transaction. If the following transaction uses either a party or a fee or both the passed data will automatically be used to load the used party or the used fee.

Immediate update

With TradeDesign Default rules typically all data dependencies are implemented. Thus (Re-)Setting properties like visibility, ReadOnly or the content is normally implemented in Default rules.

Instant checks

The TradeDesign check rules are used to define checks associated to (typically visible) fields. In check rules the TradeDesign command “Error” or “ErrorOnField” is used to signal blocking error messages.

Those check rules are automatically executed whenever a user action withdraws the focus from a field.

Full consistency checks

The TradeDesign function “checkall” is used to enforce all checks upon completion of the datentry before processing the data.

By that all fields, this includes the not touched fields, will be checked independent of the focus.

Show the system status

The TradeDesign function “Status” is used to report the completion of a user level function.

Early locking of data to be updated

The TradeDesign lock system is used to utilize logical long term locks on the relevant entry for the duration of a business transaction and technical short term locks for the duration of the database update. Conceptual a pessimistic locking approach is used with the addition that the used locks are not preventing other transactions from reading the locked data.

To avoid deadlocks the update logic utilizes the phases

  1. Identify and collect all entries which need to be updated and make sure that they are locked. In case an entry cannot be locked the update is canceled and all short term locks are released to allow a retry.
  2. Execute the necessary database updates
  3. Execute the Commit of the database transaction
dev/005bas/010tdtrnconcept.txt · Last modified: 2024/04/05 10:10 (external edit)