To make sure that database transactions are as short as possible they should not be influenced by any user interaction. The consequence of this is, that when leaving the last rule of the basic execution (typically the highest order of an event) any open database transaction must be committed. The second consequence is, it is not allowed to use prompts if a database transaction is open. Either query the necessary decision before the database transaction starts or show the result after completing the database transaction. In case a prompt occurs when a short-term lock is raised, the application raises an error and gets cancelled.

To be sure to have always a consistent database, even in case of system failures or other unexpected events it is essential to group all needed update across all the different table and entries together and signal the database the completeness of all updates by a database commit. As often there are different areas affected and each of those areas has its own update routine the application should be setup in a manner that the calling layer is the owner of the database transaction and all modules or features, which provide own update routines shall execute the needed updates and leave it to the calling layer to decide when all updates, which need to be grouped together are completed and the database transaction might get committed.

The processing sequence of a database update is divided into three phases

Check the internal data consistency

Lock (short term) all not already locked (long term) entries which need to get updated When all entries are read and held or locked the last exit of the processing is possible.

Call DbCommitStateSave to register the commit state (part of the generic rules) the database update starts and all updates to the database are executed Call DbCommitStateCheck to check for occurred Commits (part of the generic rules) The database transaction must be committed (part of the generic rules)

The above sequence is implemented typically in different order ranges of the event rules executed by the save button (e.g. MTABUT\SAV, MDABUT\SAV, MDEBUT\UPD)

Locking of entries must follow an application wide defined lock hierarchy. This hierarchy for DOKA is defined to be looking from top down the contract in the contract table (and not in CCI) and below that the transaction (TRN) the individual function/service/transaction is operating on. Same is valid for other database structures with multiple logically connected entries in one or more tables, where updates need to be done touching multiple entries. There the top object, which needs to be updated needs to be locked first before lower elements are locked.

To avoid the occurrence of deadlocks, locks should always be raised in accordance with the application wide defined lock hierarchy.

Typically, in transaction operating on a previously selected entry, the entry and the necessary connected entries are read with a long-term lock within the initialization phase of a transaction.

Locks which are needed just for the lifetime of a single basic execution and which do not require any user interaction are normally short-term (= ReadHold) locks.