This section describes data access topics that you may need to take into accout and configure during development of your Business Service.

Transactional operations on Compact Architecture

All the operations performed by the Process API layer on the Compact Architecture are transactional. In detail, all the endpoints are now compliant with the ACID properties, namely that in case of failure during a transaction, the action is undone, and any applied change is rolled back to restore the consistent state that existed before the transactional operation started. This makes all the operations performed on the Compact Architecture reliable and safe. Transactions are enabled as default choice on Compact Architecture projects.

Note
 The event subsystem in the BAMOE workflow engine does not have transactional support (see the Known Limitations section)

It is possible to disable the default behavior and make the operation no longer transactional by configuring your project application.properties with one of the properties shown in the following table:

Property Description Type Default

kogito.transactionEnabled

Globally sets transactions as enabled for the entire application

Boolean

true

kogito.processes.transactionEnabled

Sets the transactions as enabled for the Process API layer, overriding global behavior

Boolean

true

kogito.usertasks.transactionEnabled

Sets the transactions as enabled for the new User Tasks API layer, overriding global behavior

Boolean

true

Multi-threaded access to a Business Service

In an environment with multi-threaded access to a Business Service the workflow engine needs to ensure proper state of the runtime data. If a process instance, or other entity, is accessed concurrently by multiple threads, it can lead to race conditions.

Use optimistic locking to ensure that concurrent access of the same database entity (e.g., process instance) is correctly handled. You can enable optimistic locking using the following property in application.properties:

# Enable optimistic locking
kogito.persistence.optimistic.lock=true
Note
 This property has no impact if you have deactivated transactions by setting kogito.transactionEnabled to false.

  • With optimistic locking enabled, if a process instance is accessed concurrently by more than one thread, the workflow engine will throw an optimistic lock exception. This exception will then be handled by the fault-tolerance system and retried, ensuring data consistency at runtime.

    For more information on fault-tolerance settings see the SmallRye Fault Tolerance for Quarkus or resilience4j for Spring Boot.

  • With optimistic locking disabled, data consistency cannot be guaranteed during concurrent access of the runtime data in the workflow engine.