Transactions

In Distributed Query Processing (DQP) engines like Kubling, transactions play a critical role in ensuring data consistency, reliability, and correctness when a query is executed across multiple Data Sourcess or nodes in a distributed system. As mentioned here, DQP refers to the method of splitting and distributing a query into multiple independent tasks, allowing parallel processing and eventually combining the results.

Kubling supports both stateful and stateless Data Sources, which introduces complexity in implementing transaction management for stateless Data Sources. This challenge is further amplified when a Data Source is implemented programmatically, such as with Script Document Data Sources.

To address this complexity, Kubling defines transaction capabilities at the Data Source level, allowing for flexibility based on the specific requirements and behaviors of each Data Source type.

Transaction support in Actions

Actions leverage a pool of internal connections (sessions) within Kubling to execute queries, treating each query—referred to as an Operation—as an atomic transaction. This design means that a group of Operations cannot be part of a session-level transaction. This decision was made deliberately, recognizing that most use cases rely heavily on the waitUntilEffective attribute for the majority of their operations, which inherently precludes the possibility of rolling back a transaction.

Consequently, in the event of an error, Actions utilize a compensation mechanism instead of traditional rollback. For more details, please refer to the Actions documentation.