A Survey on Transactional Stream Processing

Transactional stream processing (TSP) strives to create a cohesive model that merges the advantages of both transactional and stream-oriented guarantees. Over the past decade, numerous endeavors have contributed to the evolution of TSP solutions, uncovering similarities and distinctions among them. Despite these advances, a universally accepted standard approach for integrating transactional functionality with stream processing remains to be established. Existing TSP solutions predominantly concentrate on specific application characteristics and involve complex design trade-offs. This survey intends to introduce TSP and present our perspective on its future progression. Our primary goals are twofold: to provide insights into the diverse TSP requirements and methodologies, and to inspire the design and development of groundbreaking TSP systems.

Fig. 1: Leaderboard Maintenance (LM ) [53].frameworks, such as Apache Storm, Apache Flink, and Apache Kafka Streams, have been developed, each with its own strengths and weaknesses.
The concept of combining relational queries with continuous stream processing has been proposed since the inception of the first-generation stream processing engine (SPE) [38].However, most modern SPEs either disallow the maintenance of relational tables [12] or permit (shared) relational tables to be queried during continuous query processing, but implicitly assume that relations remain unchanged throughout the lifespan of a query [5,49].Consequently, current SPEs have some limitations.First, they do not offer transactional guarantees.Second, they are unable to maintain a consistent state across distributed systems, such as the management of transactional records during stream processing [53].This has led to the emergence of TSP systems [3,7,10,19,33,40,52].
In general, a TSP system is a computing system that processes continuous streams of data while providing transactional guarantees, such as atomicity, consistency, isolation, and durability (ACID) [74].To qualify as a TSP system, a system should possess the following two fundamental characteristics: 1) enable continuous data processing: the system should be able to process incoming data streams in (near)real-time, without the need for batch processing or storing the entire dataset in memory; 2)

Transfer/Deposit
Event Stream Source Streaming Ledger Sink

AccID Balance
Account Table
offer transactional guarantees: the system should guarantee ACID properties are met, to ensure that data operations are correct, reliable, and maintain data integrity.These systems are designed to handle real-time data processing and analytics, while ensuring the correctness and integrity of data operations.

Example Use Cases
To provide context, next, we discuss two representative scenarios as motivating examples, which is then followed by some remarks.A detailed list of relevant application scenarios is presented in Section 5. Leaderboard Maintenance.Meehan et al. [53] describe a leaderboard maintenance application (depicted in Figure 1), which considers a TV show akin to American Idol.In this use case, viewers vote for their favorite contestants (via text message), and the system must continuously and accurately update and display the top contestants ranked by the total number of votes in real-time.Suppose a preferential voting scheme is employed, where the contestant with the fewest votes is periodically eliminated.Additionally, several leaderboards are maintained: one for the top-3 contestants, one for the bottom-3 contestants, and a third one for the top-3 trending contestants over the last 100 votes.With each incoming vote, these three leaderboards are continuously updated.Here, there are two key requirements.First, incoming votes need to be validated and recorded in a shared table called Votes, which requires ACID guarantees.Second, to ensure fairness, early votes need to be tallied before later votes, thereby necessitating an ordering guarantee.
Streaming Ledger.Another simplified use case that benefits from TSP is the Streaming Ledger (SL), proposed by dataArtisans [3], as illustrated in Figure 2. In this scenario, two types of requests access two tables with shared mutable states: transfers, which exchange funds between user accounts or assets, and deposits, which increase the balance on user accounts or assets.The aim is to process a stream of these requests and output the results.To handle a large volume of concurrent requests both ACID guarantees and ordering guarantees are necessary.For instance, transfers may be rolled back, if they violate data integrity, such as causing a negative account balance.Additionally, the system may need to process requests in temporal order by timestamp.
Remarks.Neither modern SPEs, nor databases adequately support the two aforementioned use cases.On the one hand, modern SPEs restrict each execution entity (e.g., each operator/thread), to maintain a disjoint subset of states (or partitioned states) [24].However, this violates a transactional consistency guarantee, when each input tuple involves multiple keys.On the other hand, databases were not designed to handle workloads with high-velocity input stream insertion.Contrastingly, TSP offers both ACID and stream processing properties in a unified manner.
Integrating streaming and transactional features is a complex task.Over the past decade, various research groups have developed their own definitions and corresponding solutions for TSP [6,19,30,37,41,59,85].This diversity stems from the wide range of application scenarios proposed in the literature, as well as the fact that each system concentrates on a specific use case, which imposes implicit assumptions and objectives.Use cases that benefit from TSP typically employ streaming capabilities to persist state or provide (near real-time) views of shared tables, while simultaneously leveraging transactional features, to ensure a consistent representation of the state or a summary of the shared tables.

Scope
This survey provides a comprehensive overview of TSP, encompassing its background, properties, design aspects, technologies, systems, and applications.We delve into the challenges and design trade-offs in implementing TSP and provide insights into the current state of the field and potential future directions.Our analysis focuses primarily on stateful stream processing, which involves the general task of processing dynamic or streaming data with algorithms that can continuously produce new results on-the-fly.While we discuss various aspects of stream processing, including dataflow engines and distributed systems, our analysis is not limited to these specific design and implementation choices.The survey emphasizes the following six aspects: • Background: Discusses the history and motivation behind stream processing and TSP, and outlines various transaction models over data streams.• Properties: Explores the key properties of TSP, such as transactions, delivery guarantees, and state management.• Design Aspects: Examines the design aspects of TSP, including languages, APIs, and system architectures.
• Technologies: Investigates the technologies used to implement TSP and how each property is addressed with potential alternatives.• Systems: Surveys representative TSP systems, focusing on their features, strengths, and weaknesses.• Applications: Presents real-world applications and scenarios where TSP is leveraged to provide valuable insights and improved decision-making.

Outline of the Survey
The subsequent sections are organized as follows.Section 2 introduces the background and overview of TSP, covering the conceptual framework of TSP systems, transaction models over data streams, and providing a high-level overview of the survey.Section 3 discusses the taxonomy of TSP systems, delving into system properties, system architecture and design aspects, and the technologies used to implement TSP.Section 4 presents a survey of TSP systems, including early and recent TSP systems, and compares them based on the taxonomy established in Section 3. Section 5 showcases various applications and use cases of TSP, such as stream processing optimization, concurrent stateful processing, and stream and DBMS integration.Section 6 highlights open challenges and future directions for TSP research and development, including novel applications and hardware platforms.Section 7 concludes with a summary of the key findings and insights gained throughout the survey.

Background
In this section, we provide a brief overview of key terms and definitions essential for understanding transactional stream processing systems, followed by a conceptual framework of TSP, and lastly, discuss several transaction models over data streams.The definitions of terms and explanations of concepts are drawn from various sources, including Babcock et al. [13].

Terms and Definitions
A data stream represents one or more underlying signals, such as a network traffic stream indicating the type and volume of data transmitted among nodes in a network.
An event e is a 2-tuple e =< t, v >, consisting of a timestamp and payload.The timestamp specifies when an event occurred, while the payload represents data values used during stream processing.
Stream queries are collections of operators that continuously process streaming events.An operator can be broadly defined as a fundamental component or unit of computation within a stream processing system.Traditional stream operators include join and aggregation, while modern SPEs also support user-defined stream operators.
Windows define bounded subsets of streams to manage infinite streams, with various window types such as tumbling, sliding, and session windows.The state is a fundamental concept in stream processing, enabling the comparison of current data with historical data.
A dataflow model is a powerful abstraction for stream processing systems, that enables parallel and distributed processing by breaking tasks into smaller units and orchestrates their execution across multiple nodes.In this model stream processing tasks are represented as directed acyclic graphs (DAGs) with nodes representing operators and edges representing the flow of data between operators.Utilizing a dataflow model allows stream processing systems to distribute workload efficiently, which in turn may increase the demand for transactional correctness guarantees.

Conceptual Framework of TSP
This section provides a comprehensive conceptual framework for transactional stream processing (TSP) systems, discussing the relationships between the key components and aspects.A TSP system is comprised of five components: transactions, transaction models, operators, scheduler, and storage.These components are closely related to the four key aspects of a TSP system, which are language, programming model, execution model, and architecture.
Transactions are critical components of TSP systems, ensuring that data is processed and maintained consistently and reliably.Transactions combine the real-time nature of stream processing with the reliability and consistency guarantees of traditional transactional systems.Transaction models describe the granularity and scope of transactions within a TSP system.In TSP, a transaction is considered committed when it has successfully completed an operation (e.g., insertion, update, deletion) and the system has confirmed that transactional changes are consistent with the desired transactional guarantees (e.g., consistency, isolation, durability).Upon committing a transaction, the system ensures that its effects are persistent and can be recovered in the event of a failure.This concept of "commit" is essential in TSP systems to maintain the integrity and consistency of the data during processing.
Operators are responsible for processing incoming and outgoing data, and performing operations, such as filtering, aggregation, transformation, or joins.Operators may also have mutable state that needs to be managed in a transactional manner.Scheduler manages the execution of operators and ensures that transactions are executed in the correct order, according to the chosen consistency and isolation models.Schedulers may need to handle out-oforder events, coordinate distributed execution, and manage resource allocation.The storage component manages the persistent state of the system, including the mutable state of operators and any intermediate or final results produced during processing.The storage component must also ensure durability and fault tolerance, while providing efficient access to the data.
The conceptual framework of a TSP system covers the key aspects to consider when designing and implementing a TSP system, including language, programming model, execution model, and architecture.
Language: The language aspect of a TSP system defines the syntax and semantics for expressing streaming and ondemand queries, as well as the transactional properties (e.g., consistency, isolation, durability).This aspect is related to the transaction models and operators, as it provides the means for developers to define and manipulate transactions and the operations they perform.
Programming Model: The programming model refers to the way developers interact with the TSP system to define and manage stateful operations and transactional guarantees.This aspect is related to transactions, transaction models, and operators, as the programming model provides the framework for working with these components in a structured and organized manner.
Execution Model: The execution model focuses on how the TSP system processes both streaming and ondemand queries while providing transactional guarantees.This aspect is related to the scheduler and operators, as the execution model determines how the scheduler manages the execution of operators and ensures that transactions are executed in the correct order, according to their consistency and isolation models.
Architecture: The architecture aspect of a TSP system addresses how the system is designed and structured to balance the requirements of stream processing and data management.This aspect is related to all five of the key components.The architecture facilitates interaction between these components, such as sharing state between on-demand and streaming queries and providing read and write access as needed.

Transaction Models over Data Streams
Next, we discuss some notable transaction models over data streams, along with their implementation approaches, to provide a comprehensive understanding of transactional guarantees in stream processing.

Abstract Models
Various transaction models have been explored for stream processing applications to address consistency guarantees.These models serve as processing paradigms in TSP systems.
Per-tuple Transactions: Each tuple in the data stream is treated as a separate transaction, adhering to ACID properties.This approach is suitable for scenarios requiring atomic and isolated processing of individual events.However, it may introduce significant overhead due to frequent coordination between processing nodes.
Micro-batch Transactions: Data streams are divided into small, bounded micro-batches, with transactions executed over them.This approach reduces the overhead associated with per-tuple transactions, allowing for parallelism and optimization opportunities.However, it may introduce additional latency.
Window-based Transactions: Transactions are executed over windows based on a unit of time, the number of events, or some other criterion.This approach enables processing of related events within the same transaction, thereby, providing stronger consistency guarantees.Yet this can be challenging to manage, especially when dealing with out-of-order events or evolving window types.
Group-based Transactions: Transactions are executed over groups of related events in the data stream.Groups can be defined based on specific criteria, providing fine-grained control over transaction boundaries, and stronger consistency guarantees for complex processing tasks.However, managing group-based transactions can be complex, requiring the identification of related events and coordination across multiple processing nodes.
Adaptive Transactions: This flexible model allows the system to dynamically adjust transaction boundaries based on workload, system state, or application requirements.This can include switching between different transaction models or adapting granularity to optimize performance or meet specific consistency guarantees.Implementing adaptive transactions can be challenging, as it requires real-time monitoring and the adaptation of transaction boundaries.

Implementation Approaches
Implementation approaches for the aforementioned transaction models can be classified into three categories: unified transactions, embedded-transactions, and state transactions.Depending on an application's specific requirements, an appropriate combination of implementation approach and particular transaction model should be chosen to achieve the desired performance, scalability, and fault tolerance capability.
Unified Transactions: This approach embeds stream processing operations into a transaction, providing a single framework for handling both stream processing and transactions.Unified transactions can potentially support various transaction models, as it allows flexibility in defining the scope and granularity of transactions.However, it might be more suitable for fine-grained transaction models, such as per-tuple or micro-batch transactions.
Embedded Transactions: This approach embeds transaction processing into stream processing, allowing for transactional semantics without the need for separate transaction management.Embedded transactions can be more efficient for certain transaction models, particularly when a lightweight transaction mechanism is required.It might be better suited for per-tuple, micro-batch, or adaptive transactions, where the overhead of separate transaction management can be minimized.
State Transactions: This approach separates transaction processing and stream processing, focusing on managing shared mutable state through transactions.State transactions can also support different transaction models, but are more suitable for scenarios where state management is a primary concern, such as window-based, group-based, or adaptive transactions.

Taxonomy of TSP
In this section, we examine a taxonomy of Transactional Stream Processing (TSP) as illustrated in Figure 3.The taxonomy is structured into three key categories: Properties of TSP: Here we examine the characteristics and requirements of TSP systems, including ordering, ACID properties, state management, and reliability.Analyzing these properties enables us to better understand the fundamental issues and challenges prevalent in TSP systems that seek to ensure accurate and reliable data processing.Design Aspects of TSP: Here we explore the design considerations in TSP systems, spanning transaction implementation, boundaries, execution, delivery guarantees, and state management.Investigating these design aspects aids us in evaluating the suitability of TSP systems for specific applications and provides insights into various design choices and trade-offs.Implementation Details: Here we address the practical aspects of TSP system implementation, such as programming languages, APIs, system architectures, and component integration.This section also discusses performance metrics and evaluation criteria for TSP systems.By examining these implementation details, we gain a deeper understanding of the practical challenges and proposed solutions in the development of TSP systems.Ultimately, this enables us to be more informed about the choices that must be made when designing or selecting which TSP system to employ for a given use case.

Properties of TSP
A TSP model is required to meet both the ordering properties of streaming operators and events, and the ACID properties of transactions, while also addressing state management, reliability, fault tolerance, and durability.These elements along with the CAP theorem's implications are crucial to the design and functionality of TSP systems.Hence, we will delve into these properties in the subsequent sections, starting with ordering properties followed by ACID properties.

Ordering Properties
In TSP systems, there are two critical ordering properties: event ordering and operation ordering.
Event Ordering: Event ordering requires that transactions be processed according to the order of their triggering events, typically based on timestamps or some other logical ordering mechanism.This property is crucial to ensure transactions are executed in the correct sequence, so as to avoid inconsistencies.It also helps prevent race conditions or out-of-order processing, which can occur in distributed TSP systems with high levels of parallelism.It is worth noting that the ordering schedule is determined explicitly by the input event rather than the transaction execution order.
To maintain event order TSP systems may employ strategies such as locking, versioning, or optimistic concurrency control.Golab et al. [37] propose two stronger serialization properties with ordering guarantees.The first is called window-serializable, which requires a readonly transaction to perform a read either strictly before a window is updated or after all sub-windows of the window are updated.The second is called latest-windowserializable, which only allows a read on the latest version of the window, i.e., after the window has been completely updated.Instead of imposing an event ordering, FlowDB [6] enables developers to optionally ensure that the effects of transactions are the same as if they were executed sequentially (i.e., in the same order in which they started).
Operation Ordering: In many TSP systems, applications can be represented using dataflow models, such as directed acyclic graphs (DAGs), where operators are connected by data streams [85].However, it is essential to acknowledge that in the TSP landscape, there may be other models that represent and process data streams using a different approach.Operation ordering refers to the sequence in  which operators are executed in a TSP system, which impacts the correctness and efficiency of the system.Via operation ordering, the data that flows through the pipeline will be processed correctly: thereby contributing to the consistency and correctness prevalent in a TSP system.When an application is represented using a DAG, the operation ordering is determined by the directed edges between the operators.Although the operation ordering may be expressed differently for alternative representations, the ordering property guarantees the outcome will be the same.Consider a scenario where a TSP system adopts a dataflow model for stream processing -the ordering property is inherently upheld in such a setup.Nevertheless, if a database system incorporates TSP, an added prerequisite for operation ordering becomes necessary to guarantee consistency and accuracy, as detailed in the work of S-Store [53].

ACID Properties
TSP can offer traditional ACID guarantees [15] similar to those in relational databases.However, depending on the requirements of the specific application, TSP systems may need to relax or adapt these guarantees.First, although ACID properties are strictly required in relational databases, they may be relaxed in stream processing scenarios [6,19,81,85].Second, some streaming applications, do not require the ACID properties [81].
Atomicity: Atomicity ensures that transactions are either fully completed or aborted.In TSP systems, all operations within a transaction are either successfully processed together or not processed at all: thereby preventing partial updates that could lead to an inconsistent state.Atomicity in TSP varies depending on the transaction model.Traditional commit protocols, such as two-phase commit (2PC), ensure atomicity by coordinating commit or abort decisions among distributed participants.In contrast, sagas [36] allow the exposure of intermediate (uncommitted) state and require developers to define compensating actions for each operation, thereby offering a more flexible way to handle atomicity at the cost of strong isolation guarantees.Some TSP systems, like the one proposed by Wang et al. [81], relax atomicity in certain contexts, which enables developers to choose the desired consistency level.In such cases, alternative atomicity models, like sagas, can be adopted to balance the trade-offs between consistency, performance, and availability.Understanding these differences is crucial for designing TSP systems with appropriate atomicity guarantees.
Consistency: Consistency ensures that a transaction moves the system from one consistent state to another consistent state [80].In the context of TSP systems, consistency guarantees that data is processed and updated according to the specified consistency model.TSP systems can provide different levels of consistency depending on the application requirements, such as eventual consistency [81], strong consistency [6], or causal consistency [85].It is essential to understand the trade-offs between various consistency levels, as stronger consistency guarantees may lead to increased complexity and reduced performance.
Isolation: Isolation prevents concurrent transactions from interfering with one another [80].In TSP systems, isolation is essential for ensuring that the output data remains consistent despite the concurrent execution of transactions.Different isolation levels can be provided by TSP systems, such as serializability, snapshot isolation, or read committed [6].The choice of isolation level depends on the application requirements and the trade-off between consistency and performance.Some TSP systems may offer configurable isolation levels, allowing developers to adjust the isolation guarantees according to the application's specific needs.
Durability: Durability guarantees that once a transaction is committed, its changes are permanently stored in the system [80].In TSP systems, durability can be ensured through techniques, such as replication, logging, or checkpointing [6].Durability plays a pivotal role in TSP systems, especially when recovery from failures and fault tolerance are considered.A system's durability influences the preservation of its state and output and governs the perceived behaviour from an external user's standpoint during a failure event.The recovery mechanism of specific TSP systems might entail replaying input streams to rebuild the state, which, due to variability in order and isolation presumptions, may not always restore an identical state.The extent of state preservation postrecovery can differ.To ensure durability, a TSP system typically needs to satisfy various properties, including input preservation, state maintenance, and output persistence.This is often achieved through strategies like replication, logging, or checkpointing, which assure fault tolerance and recoverability post-failure.to manage memory and storage resources efficiently.This ensures that the system can continue processing new transactions without running out of resources.

Reliability and Delivery Guarantees
Fault tolerance, durability, and deliverability are essential properties of TSP systems.These properties ensure that TSP systems can accurately process data and maintain their state despite potential issues, such as failures, duplicate messages, and out-of-order events.Fault tolerance and durability are essential to achieve exactly-once delivery semantics.Fault tolerance ensures a system can continue operating despite failures, while durability guarantees that committed transactions are stored permanently.Together, these properties enable the system to provide exactlyonce semantics, thereby, ensuring each event is processed correctly and without duplication or omission, even when failures occur.
Delivery Guarantees: Delivery guarantees in TSP systems dictate how input events are processed, when failures, duplicate messages, or out-of-order events occur.Common delivery guarantees in stream processing systems include at-most-once, at-least-once, and exactly-once processing.
Exactly-once processing is often the most desirable for TSP systems, ensuring each event is processed exactly once, regardless of failures or other issues during processing.Thus, even in the presence of failures, the system can ensure no duplicates or missing events occur.
Fault Tolerance: Since streaming applications typically run indefinitely, the probability of service disruptions due to unexpected system failures increases.A fault-tolerant TSP system persists when processing events and adheres to delivery guarantees, even in the face of failures.In case of a failure, a fault-tolerant system must recover and resume processing without violating delivery guarantees.
To enable rapid recovery from failures and minimize data loss, fault tolerance approaches, such as state replication, checkpointing, and log-based recovery are employed.
Durability: Durability involves persistent data storage, to ensure its availability for retrieval.This property is crucial for upholding delivery guarantees, as it enables the system to maintain desired processing semantics.For instance, in an exactly-once processing scenario, the system must ensure that each input event is processed and committed exactly once, necessitating durable storage for both the input events and corresponding state changes.
CAP Theorem: The CAP theorem, foundational in distributed systems, states a system can't simultaneously provide consistency, availability, and partition tolerance.This is of importance to Transactional Stream Processing (TSP) systems, which often must strike a balance among these properties due to distributed data processing and storage.Consistency and durability both aim to maintain a uniform view of the system's state.For TSP systems, these are crucial for preserving data integrity and providing reliable transactional guarantees.Availability, ensuring every system request receives a response, is vital for continuous, real-time processing in TSP systems.Partition tolerance, akin to fault tolerance, allows a system to function even during communication breakdowns between nodes, a key requirement in TSP systems for ensuring uninterrupted processing.Given the CAP theorem's constraints, TSP systems may need to prioritize among these properties based on specific use cases.For instance, a TSP system prioritizing consistency and partition tolerance might compromise availability, leading to longer response times.Conversely, one focusing on availability and partition tolerance may occasionally return stale data but provides fast responses and continuous operation.
Remark 1 (Beyond Exactly-Once Guarantee) TSP systems may face unique challenges requiring more stringent delivery guarantees than the exactly-once guarantee typically found in many SPEs.Specifically, TSP systems must replay failed tuples in the exact timestamp sequence of their triggering input events and prevent duplicate message processing.This is crucial because results depend on the local state of an operator and the time ordering of input streams.
One approach to achieving this advanced level of delivery guarantee involves checkpointing or archiving each input event before processing and sequentially replaying them in case of failure [26].While this method provides the desired guarantee, it incurs significant overhead, making it unsuitable for many TSP systems.Consequently, further research is required to identify more efficient mechanisms that can satisfy the delivery guarantee needs of TSP systems while minimizing performance overhead.

Design Aspects of TSP
The design aspects of TSP systems focus on the critical components required to create a functional and efficient TSP system.These components include the implementation of transactions, determining transaction boundaries, executing transactions, delivering guarantees, and managing the state.Understanding these design aspects is crucial for evaluating the suitability of different TSP systems for specific application requirements and providing insights into various design choices and trade-offs.

Implementing Transactions
To actualize a transaction model over data streams, three primary approaches have been proposed: embedding stream processing operations into transactions (i.e., unified transactions), embedding transaction processing into stream processing (i.e., embedded transactions), or combining transaction processing and stream processing (i.e., state transactions).Let us discuss each of these in turn.
Approach 1: Unified Transactions.Unified transactions integrate stream processing and transaction processing by transforming data streams into time-varying relations [10,40,55].By treating data streams and relational data uniformly, TSP systems can leverage existing relational data management techniques for transactional consistency and correctness.This approach enables us to define a transaction that can handle both stream processing and transactional aspects within a single framework, thereby, allowing flexibility in defining the transaction scope and granularity.A unified transaction T i is a tuple (D i , O i ), where D i ⊆ D and O i ⊆ O.In this approach, both stream processing and transactional aspects are handled within a single framework, allowing flexibility in defining the scope and granularity of transactions.
Several studies have explored the implementation of continuous queries as sequences of one-time queries, which are executed as a result of data source modifications or periodic execution [19,53,57,58].These studies illustrate the various methods employed to unify stream processing and transaction processing, so as to enable the use of a single execution engine for both types of operations.The design space for unified transactions consists of several aspects, including data modelling, query execution, and transaction management.
Data Modeling.In order to transform data streams into relational data, data streams are represented as time-varying relations.To indicate the time-varying nature of data, both input and output streams are treated as continuous relations with a timestamp attribute.This uniform representation enables the use of relational algebra and SQL-like queries to process data streams and simplifies the integration of stream processing with existing relational database systems.
Query Execution.Queries over data streams are often continuous: they are evaluated over an unbounded sequence of input data.Unified transactions represent continuous queries as a sequence of one-time queries triggered by data source modifications or periodic execution.This approach allows for the reuse of existing query processing techniques from relational databases while ensuring the continuous nature of stream processing is maintained.
Transaction Management.To ensure transactional consistency and correctness, the unified transactions approach relies on relational data management techniques.In particular, concurrency control and recovery mechanisms, such as two-phase locking and logging, to provide isolation, atomicity, and durability guarantees.
The unified transactions approach simplifies system architecture and leverages well-established relational data management techniques.However, this approach may introduce additional overhead due to the transformation of data streams into relational data and may not be suitable for all TSP systems, particularly those with strict latency requirements or complex stream processing needs.Developers must carefully evaluate the trade-offs and requirements of their specific application to determine whether this approach is appropriate for their TSP system.Approach 2: Embedded Transactions.The embedded transaction approach integrates transaction processing directly into the stream processing pipeline.Instead of transforming data streams into relational data, transactions are managed and processed within the context of stream processing.This approach involves event-driven processing, state management, and transactional guarantees.
Definition 2 (Embedded Transaction) Let S = s 1 , s 2 , ..., s n be a data stream, and O = o 1 , o 2 , ..., o m be a set of stream processing operations.An embedded transaction T i is a tuple (s i , O i ), where s i ∈ S and O i ⊆ O. Here, each incoming data item s i is treated as a transaction, allowing real-time processing while maintaining consistency and reliability guarantees.
Several studies, including those exploring incremental continuous query processing with isolation guarantees [67] have explored the embedded transactions approach.For instance, Shaikh et al [67] propose a model that treats each incoming data item as a transaction.This approach allows for real-time processing of data streams while maintaining consistency and reliability guarantees.However, potential issues include inconsistencies in the output due to updates during join processing.To address this, they propose a mechanism for maintaining consistency in the presence of concurrent updates, using snapshot isolation and optimistic concurrency control.
Key aspects of embedded transactions involve processing events as they arrive, managing state information between processing steps, and incorporating data partitioning, replication, and checkpointing to achieve transactional guarantees.Next, we examine each of these aspects in turn.
Event-Driven Processing.The embedded transaction approach employs event-driven processing, where each event in the data stream triggers one or more stream processing operations.This allows for low-latency processing and maintains the temporal order of data streams.
State Management.State management is crucial in the embedded approach since it enables the retention and manipulation of information between processing steps.State management varies across systems, with some using distributed storage systems or in-memory data structures for efficient state management.
Transactional Guarantees.The embedded transaction approach provides transactional guarantees, such as consistency, isolation, and durability within the stream processing pipeline.To achieve these guarantees, they employ techniques, such as data partitioning, replication, and checkpointing.
The embedded transaction approach offers benefits, such as low-latency processing and the native handling of complex stream processing tasks.Nevertheless, implementing transactional guarantees within the stream processing pipeline could necessitate substantial efforts.Furthermore, this approach might not be optimal for applications necessitating integration with established relational databases or traditional transaction processing systems.Developers should carefully assess the requirements and constraints of their specific application to determine whether this approach is appropriate for their TSP system.Approach 3: State Transactions.The state transaction approach merges transaction processing and stream processing within a single system and handles state access operations as transactions.This enables TSP systems to provide transactional guarantees while processing unbounded data streams and ensure correctness via transactional semantics and the modelling of state accesses as state transactions.
Definition 3 (State Transaction) Let S = s 1 , s 2 , ..., s n be a data stream, R = r 1 , r 2 , ..., r p be a set of shared mutable states, and O = o 1 , o 2 , ..., o m be a set of processing operations.A state transaction T i is a tuple (S i , R i , O i ), where S i ⊆ S, R i ⊆ R, and O i ⊆ O.All operations within the same transaction have the same timestamp, denoted as ts.
State transactions focus on managing shared mutable states through transactions.Key aspects include managing state information between processing steps and decoupling transaction processing from stream processing.Design considerations include dataflow models, state access operations, coordination mechanisms, and fault tolerance and recovery.Next, we examine each of these design considerations in turn.
Dataflow Models.The state transaction approach typically uses dataflow models to process data streams consisting of interconnected stateful operators.These operators process events, update state, and produce output events, which is amenable for parallel and distributed processing.
State Access Operations.State transactions treat state access operations as transactions, where each operation is associated with a unique timestamp.This enables complex processing tasks and transactional guarantees, like consistency, isolation, and durability.
Coordination Mechanisms.The state transaction approach coordinates state transactions across the dataflow pipeline using mechanisms, such as two-phase commit protocols, timestamp-based ordering, or conflict resolution strategies, to maintain consistency and isolation.
Fault Tolerance and Recovery.The state transaction approach provides fault tolerance and recovery mechanisms, such as replication, checkpointing, and logging, to ensure durability and resilience against failures.
The state transaction approach integrates transaction processing into the stream processing pipeline, handles complex processing tasks, and provides transactional guarantees.However, this approach may introduce additional complexity due to the use of coordination and fault tolerance mechanisms.Developers should carefully assess their application's requirements and weigh the benefits against the potential complexities introduced by this approach.

Determining Transaction Boundaries
Determining transaction boundaries is an essential aspect of TSP system design, as it defines which operations are grouped into transactions for atomicity.It turns out that establishing transaction boundaries over streams can be quite flexible, particularly for state transaction implementation.First, various conditions can initiate a transaction (i.e., triggering unit), such as per input event or per batch of events with a common timestamp.Second, different entities can generate a transaction (i.e., generating unit), such as per operator and per query.Additionally, transactions can spawn other transactions (i.e., transaction spawning).Let us examine each of these settings in turn.
Setting 1: Triggering Units.TSP systems diverge from traditional databases in that they rely on incoming streaming events rather than user requests to initiate transactions.The granularity of transaction boundaries is defined by various types of triggering units, including time-based, batch eventbased, single event-based, and user-defined triggers.Next, we describe each of these in turn.
Time-based Triggers.Time-based triggers refer to transactional models in which the transaction boundaries are determined by time intervals.These intervals can be either fixed or dynamically adjusted based on the application requirements or the characteristics of the data streams.It often assumes that events with a common timestamp are executed atomically to ensure progress correctness.This approach is employed in both academic projects, such as STREAM [10,40] and commercial products, like Coral8 [2].Time-based triggers are suitable for the concurrent aggregation of sliding windows, the association of transaction boundaries with window boundaries, and the management of long-running queries with specified reexecution frequencies [33,37,59].
Batch Event-based Triggers.These transactions are triggered when a batch of events with a shared characteristic (e.g., common timestamp, originating from the same stream) are processed.Batch event-based triggers are used in DataCell [47,48], S-Store [53], and Chen et al.'s cycle-based transaction model [30,31].They can handle large volumes of data and provide consistent processing across multiple streams.
Single Event-based Triggers.In this type, a transaction is triggered for each incoming event.Single event-based triggers ensure fine-grained control and consistency on an event-by-event basis.They have been implemented in various systems, such as Aurora and Borealis [4,5], ACEP [81], SPASS [63], and TStream [85].This type of transaction is suitable for applications requiring strict consistency guarantees and low-latency processing.
User-defined Triggers.In this type, users can define custom triggering conditions based on their specific application requirements, which offers flexibility when establishing transaction boundaries and declaring processing guarantees.Botan et al. [19] and Chen et al. [29] demonstrate the use of user-defined transactions in their respective systems.
Setting 2: Generating Units.While triggering units determine "when" a transaction is created, generating units focus on "who" generates a transaction.Transactions can be generated by user clients directly or through continuous queries on a per-query or per-operator basis.The design space for generating units includes query-based, operatorbased, and user-defined generators.Next, we describe each unit type in turn.
Query-based Generator.These transactions group operations involved in the one-time execution of an entire query [10,40].Early Stream Processing Engines (SPEs) employed query-based triggers for the interactive processing of both relational and streaming data, such as the STREAM project [10,40].This type simplifies the transactional model, making it easier to manage and understand.However, it may lack flexibility in some cases, where individual operators within a query need to have separate transactional boundaries or different isolation levels.
Operator-based Triggers.In this type, each operator in a query generates its own transactions [53,85].Examples of this design include S-Store [53] and TStream [85].Operator-based triggers provide a finer level of granularity and flexibility compared to query-based triggers, which enables more precise control over shared states in streaming dataflow graphs.This can lead to better performance and resource utilization in certain scenarios.However, this increased flexibility may also result in potential conflicts or dilemmas, such as deadlocks and contention, which may require additional mechanisms to resolve [53,85].
User-defined Triggers.Some applications may require ad-hoc transactional queries or user-driven transactions during stream processing [6,7,29].User-defined transactions allow users to specify where consistency needs to be enforced and which consistency constraints are required, as demonstrated in the work of Affetti et al. [6,7].This type grants more control to the user, thereby, allowing them to tailor transactional semantics to their specific needs.However, this flexibility can make system-level optimizations more challenging, as the transaction types are not known in advance.Additionally, users bear the Implement the semantics of database transactions to defined segments of data streams, thereby assuring snapshot isolation during the processing of these segments responsibility of ensuring that the system is free of any dilemmas or conflicts [6,7].
Setting 3: Transaction Spawning.Transactions can also spawn, i.e., trigger and generate other transactions.This is particularly useful in service-oriented architectures, where the basic premise is to treat all functionalities as services and compose and execute them, according to the user or application-specific requirements [79].Treating each service execution as a transaction and requiring atomic execution of those transactions have been found to be very helpful in this process.The execution of service compositions yields composite transactions [78], where a transaction is an execution of a service [77].Subsequently, a transaction spawning consists of a nonempty set of services.Some of these have executions that are continuous and others may spawn new transactions.

Executing Transactions
Executing transactions involves processing the operations within a transaction according to the defined transaction boundaries and ensuring that the system maintains the required properties including the ACID properties and also the streaming properties.In STREAM [40], synopses enable different operators to share common states.To guarantee that operators view the correct version of a state, the system must track the progress of each stub and present the appropriate view (i.e., a subset of tuples) to each stub.This is achieved through a local timestamp-based execution model with a global schedule that coordinates the successive execution of individual operators via time slot assignments.Batches of tuples with the same timestamp are executed atomically to ensure progress correctness, with a simple lock-based transactional processing mechanism implicitly involved.
An earlier study by Wang et al. [81] describes a strict two-phase locking (S2PL)-based algorithm that allows multiple state transactions to run concurrently while maintaining both ACID and streaming properties.Unlike the original S2PL [15] algorithm, Wang et al. [81] lock each transaction ahead of all query and rule processing.In this process, each transaction's timestamp is compared against a monotonically increasing counter to ensure that the transaction with the smallest timestamp always obtains a lock first, thereby guaranteeing access to the proper state sequence.Once lock insertion is complete, the system increases the counter and allows the next transaction to proceed, regardless of whether the transaction was fully processed.To fulfil event ordering constraints, read or write locks are strictly invoked in their triggering event order.However, the locking mechanism must synchronize the execution for every single input event, which may negatively impact system performance.
Oyamada et al. [57] propose three pessimistic transaction execution algorithms: synchronous transaction sequence invocation (STSI), asynchronous transaction sequence invocation (ATSI), and order-preserving asynchronous transaction sequence invocation (OPATSI).STSI processes transactions triggered by event streams one at a time, with execution results naturally generated following the event arrival sequence.ATSI removes the blocking behaviour of STSI by asynchronously spawning new threads that wait for the transaction to complete.OPATSI extends ATSI through a priority queue to further guarantee the order of the results.b) Multi-version lock-based: These approaches employ multiple versions of shared states and use locks to control access to different state versions.The main challenge is ensuring that the correct state version is accessed while avoiding outdated writes.
A notable example is Wang et al. [81], who propose an algorithm called LWM (Low-Water-Mark), which relies on the multi-versioning of shared states.LWM leverages a global synchronization primitive to guard the transaction processing sequence: write operations must be performed monotonically in event order, but read operations are allowed to execute as long as they can read the correct version of the data (i.e., its timestamp is earlier than the LWM).The key differences between LWM and the traditional multi-version concurrency control (MVCC) scheme are twofold.First, MVCC aborts and then restarts a transaction when an outdated write occurs, while LWM ensures that writes are permitted strictly in their timestamp sequence, preventing outdated writes.Second, MVCC assumes that the timestamp of a transaction is systemgenerated upon receipt, whereas LWM sets the timestamp of a transaction to the triggering event.This distinction enables LWM to maintain a more event-driven approach to transaction management, better aligning with the streaming nature of TSP systems.
In summary, lock-based approaches to transaction execution in TSP systems offer various methods for managing access to shared resources and maintaining consistency.While single-version lock-based approaches focus on balancing synchronization and performance within a single shared state, multi-version lock-based approaches provide greater flexibility by managing multiple versions of shared states.Both types of approaches present their own challenges and trade-offs, and the choice of approach depends on the specific requirements and characteristics of the TSP system being implemented.
Partition-based Approaches: Partition-based approaches to transaction execution in TSP systems involve dividing the internal states or transactions into smaller units, which can then be executed in parallel or with reduced contention.These methods aim to improve performance while maintaining consistency and adhering to event order constraints.There are two primary types of partition-based approaches: a) Static partition-based: These approaches divide the internal states of streaming applications into disjoint partitions and use partition-level locks to synchronize access.This approach is suitable for transactions that can be perfectly partitioned into disjoint groups.
For example, S-Store [53] splits the streaming application's internal states into multiple disjoint partitions.The computation on each sub-partition is performed by a single thread.To guarantee state consistency, S-Store uses partition-level locks to synchronize access.However, the state partition-based approach only performs well on transactions that can be perfectly partitioned into disjoint groups, given that acquiring partition-level locks on crosspartition states significantly impacts performance due to the overhead.
b) Dynamic partition-based: These approaches involve decomposing transactions into smaller steps and executing them in parallel to improve performance while ensuring serializability and meeting event order constraints (e.g., TStream [85] and MorphStream [50]).
The sagas model [36] allows a transaction to be split into several smaller steps, each of which executes as a transaction with an associated compensating transaction.Either all steps are executed or in a partial execution compensating transactions are executed for steps that are completed.Thus, isolation is relaxed in the original transaction and delegated to the individual steps.It exposes an intermediate (uncommitted) state and requires developers to define compensating actions.A similar idea of splitting transactions has been adopted in TSP systems such as TStream [85] and MorphStream [50] but does not expose uncommitted states and hence does not require compensating actions.
In particular, TStream [85] is a recently proposed TSP system that adopts transaction decomposition to improve stream transaction processing performance on modern multicore processors.Despite the relaxed isolation properties, TStream ensures serializability, as all conflicting operations (being decomposed from the original transactions) are executed sequentially as determined by the event sequence.The successor of TStream [85], MorphStream pushes the idea further and proposes costmodel guided dynamic transaction decomposition and scheduling to further improve the system performance.
Optimistic Approach: Optimistic approaches avoid locking resources by employing timestamps and conflict detection mechanisms to maintain transaction consistency at the desired isolation level, aborting and rescheduling transactions when necessary.These approaches handle transactions by predicting the order of events or by performing speculative execution to improve system performance.The challenge is to ensure that speculation is accurate and efficiently manages rollback or recovery when needed.
Golab et al. [37] present a scheduler targeting window serializable properties, which optimistically executes window movements and utilizes serialization graph testing (SGT) to abort any read-only transactions causing read-write conflicts.A conflict-serializable schedule is achieved if the precedence graph remains acyclic.They also suggest reordering read operations within transactions to minimize the number of aborted transactions, thereby improving the schedule.FlowDB/TSpoon [6,7] propose an optimistic timestamp-based protocol that refrains from locking resources and instead uses timestamps to ensure transactions consistently read or update versions aligned with the desired isolation level.If this is not feasible, transactions are aborted and rescheduled for execution.This approach aims to minimize contention and improve performance by avoiding lock-based mechanisms while still maintaining the necessary consistency and isolation requirements.
Snapshot Isolation Approach: These approaches employ snapshot isolation to split a stream into a sequence of bounded chunks and apply database transaction semantics to each chunk.Processing a sequence of data chunks generates a sequence of state snapshots.By storing multiple versions of values as commit and delete timestamps, readers can access the latest version of a state, ensuring consistency and isolation among concurrent transactions.
A number of TSP systems employ snapshot isolation [4,19,30,32,39], aiming to split a stream into a sequence of bounded chunks and apply the semantics of a database transaction to each chunk.By putting the operation on a data chunk within a transaction boundary, a state snapshot is produced.In this way, processing a sequence of data chunks generates a sequence of state snapshots.For example, Gtze and Sattler [39] present a snapshot isolation approach for TSP.Each state has multiple versions of values, each stored as a commit timestamp, delete timestamp, and value.Consequently, readers can access the latest version of a state using the commit and delete timestamps.This approach provides consistency and isolation among concurrent transactions while avoiding the need for locking mechanisms, which can improve system performance.

Ensuring Delivery Guarantees
In this subsection, we explore various design aspects of TSP systems that help ensure reliability and delivery guarantees.We discuss strategies for achieving ACID properties and streaming properties under failures and their implications on TSP system design.For a comprehensive survey on fault tolerance mechanisms in SPEs, refer to [75].While modern SPEs usually offer fault-tolerance mechanisms while ensuring various delivery guarantees, they may not always fulfil the requirements of TSP due to the combined need to satisfy ACID and streaming properties.
Achieving ACID Properties: In the event of a failure, TSP systems generally need to recover all states, including input/output streams, operator states, and shared mutable states.This ensures committed transactions remain stable, while uncommitted transactions do not impact this state.Transactions that have started, but have not yet been committed should be undone upon failure and reinvoked with the correct input parameters once the system is stable again.This necessitates an upstream backup and an undo/redo mechanism akin to an ACID-compliant database.
For instance, TSP systems must guarantee atomicity when updating shared states, even under failures.An atomic transaction ensures a commit either fully completes the entire operation or, in cases of failure (e.g., system failures or transaction aborts), rolls back the database (or shared states in TSP) to its pre-commit state.Journaling or logging in database systems mainly accomplish atomicity, while distributed database systems require additional atomic commit protocols to ensure atomicity.Regrettably, most prior works on TSP either do not explicitly mention their mechanisms to ensure atomicity under failure [6,85] or rely on mechanisms provided by their storage systems (e.g., traditional database systems [53]).Making this more transparent could help users better understand which properties are not guaranteed when employing a TSP system in practice.
Achieving Streaming Properties: To satisfy streaming properties further, the recovered states in TSP systems should be equivalent to the one under construction when no failure occurred.Achieving this requires an order-aware recovery mechanism [70].However, the commonly adopted recovery operation in modern SPEs, particularly the parallel recovery operation, might result in different transactional states due to the absence of guarantees on the event processing sequence during recovery.To the best of our knowledge, there is still no in-depth study on designing efficient fault tolerance mechanisms for TSP systems.
Additionally, distributed SPEs often adopt a form of eventual consistency [14] to ensure high availability, as states exposed to the external world are expressed as output streams, and instant consistency of the global system state is hidden from users.Eventual consistency informally guarantees that if no new updates are made to a given data item, all accesses to that item will eventually return the last updated value.However, it is unclear how such a relaxed model (i.e., eventual consistency) can be applied to TSP to achieve fault tolerance and high availability, given that shared mutable states (or their snapshot) need to be immediately visible and queryable both internally and externally to the system.

Implementing State Management
State management is a crucial aspect of transactional stream processing (TSP) systems, as it enables the coordination of concurrent transactions, maintains consistency, and provides fault tolerance [9,85].The design space for state management in TSP systems can be characterized by several dimensions, such as access scope, storage model, data manipulation statements, and state management strategies.Next, we delve into these dimensions and explore their implications for system design and optimization.
Access Scope: The access scope of state management ranges from intra-operator to inter-systems.Depending on the application's requirements, TSP systems may need to manage state locally within a processing node or share state across multiple nodes or even external systems [24,39].It is worth noting that when OLTP workloads are implemented in a TSP system, the access scope of a shared state is within a transaction, which can be attributed to a single operator or multiple operators.a) Intra-operator state management focuses on maintaining state among instances of a single operator, making it suitable for applications with localized data access patterns and minimal coordination requirements [37].b) Inter-operator state management involves sharing state across multiple operators within the same query/system [6,85].This approach is particularly relevant for applications that require coordination among different operators.c) Inter-system/global state management extends the scope of state sharing even further, enabling TSP systems to exchange state information with external systems, such as other stream processors, databases, or distributed file systems [52].This approach allows TSP systems to leverage the capabilities of external systems, such as query processing or storage, and can facilitate seamless integration with existing data processing pipelines.However, managing state across system boundaries can introduce additional complexity, latency, and potential consistency issues.
Storage Models: There are two primary storage models for implementing state management in TSP systems: relations and key-value pairs.Each has its trade-offs and implications for system design and optimization.
a) Relations: In this model, states are represented as time-varying relations that map a time domain to a finite but unbounded bag of tuples adhering to a relational schema [40,53].This approach leverages well-developed techniques from relational databases, such as persistence and recovery mechanisms.Storing states as relations can help minimize system complexity, especially when a foreign key constraint is required in TSP [52].However, incorporating time into the relational model can add complexity to query processing and optimization [40].
Representative examples include STREAM, S-Store, and TStream.STREAM [40] represents the state as a timevarying relation, mapping a time domain to a finite, but unbounded bag of tuples adhering to the relational schema.
To treat relational and streaming data uniformly, STREAM introduces two operations: To Table to convert streaming data to relational data, and To Stream to convert relational data to streaming data.S-Store [53] does not implement its own state management component, but instead relies on H-Store [72] to ensure the transactional properties of shared states represented as relations.TStream [85] uses the Cavalia relational database [83] to support the storage of shared states.
b) Key-Value Pairs: In this model, states are represented as key-value pairs, which simplifies the design of TSP systems [9,24].This approach is suitable for scenarios that mainly require select and update statements for manipulating shared states during stream processing [7,50].However, it may not be the best choice for applications that require more complex data manipulation operations or constraints, such as foreign key constraints [52].
Representative examples include MillWheel [9], Flink with RocksDB, AIM (Analytics in Motion) [20], FlowDBMS/TSpoon [6,7], and TStream/MorphStream [50,85].MillWheel [9] maintains state as an opaque byte string on a per-key basis, with users implementing serialization and deserialization methods.The persistent state is backed by a replicated and highly available data store, such as Bigtable [28] or Spanner [34], ensuring data integrity and transparency for the end user.Flink [24] relies on an LSM-based key-value store engine called RocksDB [1] to support shared queryable state.G"otze and Sattler [39] also adopt a key-value store for transactional state representation, using multi-version concurrency control, where each state (i.e., key) has multiple commit timestamps, delete timestamps, or values.
AIM [20] represents state in a distributed in-memory key-value store, where nodes store system state as horizontally-partitioned data in a ColumnMap layout.The Analytics Matrix system state provides a materialized view of numerous aggregates for each individual customer (subscriber).When an event arrives in an SPE, the corresponding record in the Analytics Matrix is updated atomically.In FlowDBMS/TSpoon [6,7], a key-value store is employed, with the state maintained by a special type of stateful stream operator called the state operator.All state access requests must be routed to and subsequently handled by state operators defined in the application.
Data Manipulation Statements: TSP systems need to define and support different data manipulation statements employed in applications that constrain both system design and potential optimizations.These statements may include operations such as insert, update, delete, and query, which must be executed efficiently and consistently in the context of transactional stream processing.
Storing shared states as relations could be a reasonable choice of system design when applications require insert (I) or delete (D) statements and need to maintain foreign key constraints, such as in the case of streaming ETL [52].However, when applications only need select (S) and update (U) statements for manipulating shared states during stream processing, storing shared states as vanilla keyvalue pairs is sufficient and simplifies the design of TSP systems.Specific optimizations should be adopted by the TSP systems according to application needs.

State Management Strategies:
The choice of state management strategy can significantly impact system performance, fault tolerance, and scalability [9,24,72].There are three main strategies for managing state in TSP systems: a) In-memory state: This strategy maintains state within the processing nodes' memory, enabling low-latency access.However, it can be limited by available memory and may require replication and distributed transactions for fault tolerance and consistency guarantees [20,85].b) External state stores: In this strategy, state is stored in external systems, such as transactional databases or distributed key-value stores with transactional support [1,39].This approach allows for improved fault tolerance, consistency guarantees, and scalability but may introduce additional latency [28,34].c) Hybrid state management: This approach combines the advantages of in-memory state and external state stores, using in-memory caching to minimize latency and external transactional storage for fault tolerance, consistency guarantees, and scalability [6,7].

Remark 2 (Failure of Concurrency Control Protocols)
Conventional concurrency control (CC) protocols, which are widely used in OLTP database systems, fail to guarantee the properties of TSP Systems.To illustrate why, we use a conventional timestamp-ordering concurrency control (T/O CC) [16] as an example.Similar discussions can be also found in a prior work [81].Let txn 1 = write(k1, v1) and txn 2 = read(k1) be two distinct transactions.For simplicity, let us assume that there are only these two transactions in the system.If txn 2 .ts> txn 1 .ts,then both txn will be successfully committed.
However, their serial order would be txn 2 → txn 1 , which violates the event order constraint (i.e., txn 2 will wrongly read the original value of k1).On the other hand, if txn 2 .ts< txn 1 .ts,then txn 2 will be successfully committed.However, txn 1 will be aborted as the writes will come too late.Aborting a transaction that represents an undo of an externally visible output or action may not be acceptable in TSP applications.
Similarly, in other conventional CC protocols, either the results are in the wrong serial order or one of the transactions has to be aborted, which eventually will result in the wrong serial order upon a restart.In other words, conventional CC Remark 3 (Timestamp Assignment Dilemma) In TSP systems, a transaction triggered by a corresponding input event should ideally take effect with minimal latency after the event occurs [81].This concept is related to external consistency or linearizability in distributed systems theory.In this setting, the timestamp of the transaction is set to be the same as the timestamp of its corresponding triggering event.When all transactions are generated by external events, the transaction schedule is aligned with an external event sequence, satisfying the event ordering constraint.
However, a dilemma arises when transactions can also be generated by internal events (i.e., outputs generated by operators) with timestamps assigned according to input events, as illustrated in Figure 4.In the DAG, each operator can produce output streams and generate stream transactions.Suppose operator A receives input event e and generates two events e a and e ′ a , passed to operators B and C, respectively.Further, suppose operator C processes e ′ a , generates e c as an output, and then passes e c to operator B. Now, let us assume operator B processes two events e a and e c and generates two transactions txn e a and txn e c , respectively.In addition, operator C processes event e ′ a and generates transaction txn ′ e a .On the one hand, txn e a must be committed jointly with txn e c , for otherwise, the event ordering constraint would be violated.On the other hand, txn e c cannot be generated before txn ′ e a is committed, for otherwise, this would violate the operator ordering constraint, which means txn e a is unable to be committed.The system then runs into a deadlock situation, where txn e a and txn ′ e a are infinitely waiting for each other to be committed.
There are two approaches to prevent this dilemma: 1) an additional ordering constraint can be enforced between operators B and C, or 2) different timestamps could be assigned to the generated events: e a , e ′ a , and e c .However, to date, we are not aware of any generally efficient solution to address such a dilemma.

Technologies Employed in TSP Implementation
This section delves into the practical aspects of implementing TSP systems, such as the choice of programming languages and APIs, system architectures, and the integration of various components to achieve a well-rounded TSP system.We also discuss performance metrics and evaluation criteria for TSP systems.

Languages and APIs
TSP systems should provide user-friendly and expressive languages that can easily define complex transactions, data manipulations, and processing logic over data streams while addressing aspects such as ordering properties, state management, and delivery guarantees.However, TSP systems do not yet have a standard transaction model or language, which complicates the selection of appropriate languages and APIs.Let us examine both declarative languages and functional languages in turn.
Declarative Languages: The STREAM system [10,40,55] supports a declarative query language called CQL (Continuous Query Language), which is designed to handle both relational data and data streams.Coral8's [2] continuous computation language (CCL) has a SQL-like syntax and supports both data streams and event streams.Franklin et al. [35] introduced TruSQL, a relational stream query language that fully integrates stream processing into SQL, including persistence.These relational stream query languages are well-suited for TSP when handling a single query at a time.However, they may not sufficiently address TSP-specific issues like isolation and concurrent execution of queries.Declarative languages need to be extended to provide proper isolation guarantees.Moreover, they need to facilitate the correct interaction among queries by incorporating features that explicitly express proper interactions or defining interaction constraints as separate rules.

Functional
Languages: Functional languages [9], influenced by MapReduce-like APIs are more suitable for expressing state abstractions and complex application logic than SQL-like declarative languages.Streaming systems, like Flink embed functional/fluent APIs into general-purpose programming languages, which allow users to define custom dataflows akin to the Aurora system [5].This design is also present in TSP systems, such as FlowDBMS and TStream [6,7,85].These languages offer greater flexibility and expressiveness, enable developers to create custom processing logic, and leverage existing functional programming paradigms.However, they may introduce additional complexity and a steeper learning curve for developers new to TSP systems.Further research is needed to explore the trade-offs between the simplicity of declarative languages and the flexibility of functional languages, as well as to develop new programming constructs and abstractions that strike a balance between the two approaches, considering the transactional requirements of TSP systems.

System Architectures
Given the properties and requirements discussed, TSP applications usually necessitate the use of SPEs in conjunction with data storage and analysis frameworks, such as database management systems (DBMSs), to create software architectures that integrate data storage, retrieval, and mining.Three approaches can be employed to construct a TSP system: 1) extending a DBMS, 2) embedding a DBMS in an SPE, and 3) composing a DBMS and an SPE.The choice of architectural approach for TSP systems depends on the specific requirements and constraints of the stream processing application.Each approach offers a unique set of trade-offs and considerations, making them more or less suitable for different use cases.By understanding the strengths and weaknesses of each approach, developers can make informed decisions when designing and implementing TSP systems to meet the needs of their applications.Next, we explore each approach in turn.
Extending a DBMS: Extending a DBMS for TSP involves incorporating stream processing functionality into traditional database management systems.By doing so, these systems aim to provide a unified platform for stream processing and traditional database management tasks while maintaining the strong consistency, isolation, and fault tolerance properties of traditional databases.Since state is managed directly within the DBMS, it can be shared across queries and operators, and provide durability and consistency.Since transactions are supported in underlying DBMS, it offers strong consistency guarantees.This setup is particularly advantageous in applications, such as financial systems, where the integrity and correctness of the data are paramount.
Notable examples of this approach include DataCell [48], MaxStream Truviso Continuous Analytics system (TruCQ) [44], and S-Store [53].While extending a DBMS for TSP offers a unified platform, it also has limitations, such as difficulty in efficiently supporting native or hybrid stream processing applications and challenges in handling real-time processing and stateful operations.Consequently, alternative approaches might be more suitable for specific TSP applications.
Advantages of this approach include: a) leveraging the existing features and infrastructure of a DBMS for transactional support, query processing, and data management; b) simplifying the system architecture by integrating stream processing functionality within the DBMS, reducing the need for additional components or interfaces; and c) potentially providing strong consistency guarantees by directly utilizing the transactional mechanisms of the underlying DBMS.Disadvantages include: a) potentially being less flexible and adaptable to the specific requirements of stream processing applications, as it inherits the architectural constraints of the underlying DBMS; and b) possibly having limited scalability and performance due to the constraints of the underlying DBMS, which may not be designed for high-velocity, high-volume data streams.
Embedding a DBMS in an SPE: The embedding approach involves integrating an SPE with an embedded key-value store or DBMS to manage state, provide transactional support, and handle storage capabilities.This method enables stream processing systems to take advantage of the features of the embedded DBMS while maintaining the flexibility and efficiency of stream processing.In this approach, state management occurs within the embedded DBMS, which can also be shared across queries and operators.However, the sharing model depends on the specific integration between the SPE and the embedded DBMS.Durability can be achieved via the underlying DBMS.
Examples of this approach include Aurora [5] and its successor Borealis [4], TStream [85] and its successor MorphStream [50].Embedding a DBMS within an SPE allows for various transactional models over streams but also introduces challenges such as integration complexity and potential performance bottlenecks or resource contention issues.This approach is better suited for applications that require a balance between the performance and scalability of stream processing and the transactional support and data management capabilities of a DBMS.It can be particularly useful when the stream processing workload is dynamic and demands efficient state management and transactional support.Examples of such applications include real-time analytics, social network analysis, and large-scale data processing tasks like log analysis or clickstream processing.
Advantages of this approach include: a) enabling TSP systems to benefit from the features of both the SPE and the embedded DBMS, combining their strengths and providing a unified platform for stream processing; and b) offering improved performance and scalability by facilitating concurrent data processing and state management, as well as leveraging the distributed nature of modern SPEs.Disadvantages of this approach include: a) necessitating careful integration of the embedded DBMS with the SPE, which may increase complexity and impact overall system latency; and b) the performance of the embedded DBMS might be influenced by the stream processing workload, potentially causing bottlenecks or resource contention issues.These problems can be mitigated by carefully tuning the embedded DBMS for the specific use case.
Composing a DBMS and an SPE: The composing approach involves using both a DBMS and an SPE in conjunction while keeping them as separate components.This method offers flexibility, adaptability, and optimizability for various application requirements.The SPE primarily focuses on processing streams, while the DBMS handles state management, transactional support, and storage capabilities.In this approach, state is managed within the DBMS, while the SPE processes the streams.Sharing state across queries and operators depends on the communication and synchronization between the SPE and DBMS.Durability can be achieved via the underlying DBMS, but the communication latency between the components can impact performance.
Examples of this approach include Storage Manager for Streams (SMS) [17].Although composing a DBMS and an SPE is more complex than other approaches and introduces additional challenges, such as performance overhead and latency in communication between the systems, it provides a flexible and scalable solution for building TSP systems that can leverage the strengths of both components.The composing approach is wellsuited for applications requiring high levels of flexibility, adaptability, and performance, as well as the ability to separately optimize and customize the SPE and the DBMS components.It is particularly useful for applications with diverse and evolving requirements, as it enables the system to be easily adapted or extended to accommodate new functionality or optimizations.Examples of such applications include IoT systems, sensor networks, and other data-intensive applications with varying processing and storage requirements.
Advantages of this approach include: a) offering the most flexibility and adaptability by allowing separate optimization and customization of the SPE and the DBMS, enabling tailored solutions for specific application requirements; and b) providing better scalability and performance by distributing workloads across multiple systems and enabling parallelization of processing tasks.Disadvantages of this approach include: a) demanding additional effort to ensure integration correctness, which may increase development and maintenance complexity.This challenge can be mitigated by using standardized interfaces and middleware for communication between the SPE and the DBMS; and b) potentially exhibiting higher latency due to the need for communication and synchronization between the SPE and the DBMS.However, this can be mitigated by optimizing communication protocols and leveraging caching techniques to minimize data exchange overhead.

Performance Metrics of TSP Systems
In this subsubsection, we discuss the key performance metrics and evaluation criteria for transactional stream processing systems.These metrics help in understanding the efficiency and effectiveness of various TSP architectures, as well as in identifying the trade-offs associated with different system designs.
Throughput: Throughput is a measure of the number of transactions or events processed per unit of time.High throughput is desirable in TSP systems, as it indicates the system's capability to handle large volumes of data efficiently.Throughput can be affected by factors such as system architecture, resource allocation, and workload characteristics.TSP systems should be designed to maximize throughput while maintaining other performance guarantees, such as low latency and correctness.Latency: Latency is the time taken for a transaction or event to be processed by the TSP system, from the moment it enters the system until it is completely processed.Low latency is crucial for TSP systems, as many real-time applications require timely processing of data.Latency is influenced by factors such as system architecture, data processing complexity, and resource utilization.TSP systems should be designed to minimize latency, ensuring that transactions are processed quickly without compromising other performance aspects.
Scalability: Scalability measures the ability of a TSP system to handle increasing amounts of data and concurrent transactions without significant performance degradation.As the volume of data and the number of concurrent transactions grow, TSP systems must be able to scale effectively to maintain low-latency access and fault tolerance.Techniques such as data sharding, partitioning, and replication can be employed to distribute the shared mutable state across multiple nodes, providing horizontal scalability.
Correctness Guarantee: Correctness guarantee in TSP systems refers to the extent to which a system can ensure data consistency and maintain the required transaction properties, as discussed in subsection 3.1, in the presence of failures, network delays, or other factors.This includes support for various isolation levels, consistency models, and durability guarantees.TSP systems should be designed to provide the appropriate level of correctness guarantees based on the specific requirements of the stream processing application.
• Isolation Levels: TSP systems should maintain proper isolation levels (e.g., serializable, snapshot isolation, read committed) to ensure that concurrent transactions do not interfere with each other and result in incorrect data processing.• Consistency Models: Different TSP systems may adopt different consistency models (e.g., strong consistency, eventual consistency, or causal consistency) to provide a balance between data correctness and system performance.The choice of consistency model should be aligned with the application requirements and the tolerance for temporary inconsistencies.• Durability Guarantees: TSP systems should ensure that once a transaction is committed, its effects are permanently recorded, even in the presence of failures.This can be achieved through techniques such as logging, checkpointing, and replication.
Balancing correctness guarantees with other performance metrics, such as throughput and latency, is crucial for achieving optimal performance in TSP systems.It is essential to recognize that the choice of the appropriate correctness guarantee is highly dependent on the application's requirements and the nature of the data being processed.For some applications, strong consistency and high isolation levels might be necessary, while for others, relaxed consistency models and lower isolation levels might be sufficient.

Systems Offering Transactional Stream Processing
We summarize six notable transactional stream processing (TSP) systems in Table 2.These TSP systems showcase the various approaches used to address the challenges in transactional stream processing.Each system offers unique features and each has made some design choices that cater to different application requirements.Let us explore each of these systems in turn, to gain some insight into the design and implementation of TSP systems.STREAM: STREAM [40] is an early TSP system that introduces a unified framework for continuous query processing over data streams and relations.It supports ACID properties and offers at-least-once delivery guarantees.STREAM's design approach is based on a combination of a sliding-window model and a relational model for efficiently processing continuous queries.It employs a language called CQL (Continuous Query Language) to express queries, which can be translated into efficient query plans for execution.STREAM supports ACID properties and at-least-once delivery guarantees.The system focuses on ordering properties and state management properties by using windows and panes for efficient state handling.The architecture of STREAM is centered around a relational model, which simplifies the integration of stream processing and transaction processing.
Botan et al.: Botan et al. [19] proposed a TSP system that focuses on a pipelined architecture for efficient parallel execution.The system supports ACID properties, but does not explicitly specify the delivery guarantees.Its design approach is centered around per-tuple transactions, which ensures strong consistency guarantees and high isolation.Botan et al. also address the challenges of implementing transactional guarantees in a stream processing environment, such as handling failures and maintaining consistency among shared mutable state.They propose techniques for addressing these challenges, including state replication, checkpointing, and recovery mechanisms.The system adheres to ACID properties, while delivery guarantees are not explicitly mentioned.The system addresses fault tolerance and durability by employing state replication, checkpointing, and recovery mechanisms.
S-Store: S-Store [53] is a state-transaction TSP system that builds upon H-Store, a distributed, main-memory relational database system.It extends H-Store with stream processing capabilities and supports ACID properties.S-Store offers various delivery guarantees, such as exactly-once and at-least-once processing semantics.The system employs a partitioning mechanism for efficient parallel execution  [20] presented a TSP system that focuses on in-database analytics by combining eventprocessing and real-time analytics within the same database.
The system supports ACID properties.However, the delivery guarantees are not explicitly specified.Its design approach is centered around in-database stream processing, which allows the system to efficiently handle complex event processing and real-time analytics tasks without requiring external tools or components.The system supports ACID properties, while delivery guarantees are not specified.The system also emphasizes performance metrics and evaluation of TSP systems, showcasing its efficiency in handling large volumes of data and complex analytics tasks.
FlowDB: FlowDB [6] is a TSP system that integrates stream processing and consistent state management.It supports ACID properties and provides exactly-once delivery guarantees.The system's design approach is based on a state-transaction model, which allows for efficient management of shared mutable state.FlowDB features a language called FQL (Flow Query Language) for expressing continuous queries and supports the integration of custom stream processing operators and user-defined functions.FlowDB supports ACID properties, exactly-once delivery guarantees, and efficient state management.It also addresses fault tolerance and durability by employing checkpointing and recovery mechanisms.
TStream/MorphStream: TStream [85] and its successor MorphStream [50] are TSP systems that emphasize efficient concurrent state access on multicore processors.These systems support ACID properties and offer exactly-once delivery guarantees.TStream's design approach includes a unique dual-mode scheduling strategy that combines transactional and parallel modes, to enable the system to maximize parallelism opportunities offered by modern multicore architectures.TStream's dynamic restructuring execution strategy further improves concurrency by adapting the execution plan based on observed state access patterns during runtime.Unlike other works, TStream focuses on improving the performance of concurrent state access on multicores with efficient execution mechanisms, and delivery guarantees.
5 Applications/Scenarios Leveraging TSP TSP arises in varying domains, such as healthcare [81], the Internet of Things (IoT) [19], and e-commerce [6]).Table 3 summarizes thirteen scenarios.Each application encompasses diverse features, transactional models, and implementations of TSP systems.We can categorise them into four scenarios: stream processing optimization, concurrent stateful processing, stream & DBMS integration, and recoverable stream processing.

Stream Processing Optimization
Several works have proposed the consistent management of shared mutable states to optimize stream processing.Below we discuss these works in the context of stream processing optimization across four use cases: sharing intermediate results, multi-query optimization, deterministic stream operations, and prioritizing query scheduling.Sharing Intermediate Results.In the STREAM system [40], nearly identical states, or synopses, within a query plan are kept in a single store to reduce storage Table 3: Summary of application scenarios and their demands of TSP properties.
redundancy.Operators access their states exclusively via a stub interface.As operators are scheduled independently, they require slightly different data views, so STREAM employs a timestamp-based execution mechanism for correctness.Ordering properties are crucial in this scenario.Event ordering constraints maintain the data stream order, while operation ordering constraints ensure transaction operations' order.ACID properties maintain the correctness and consistency of shared mutable states.State management properties require read-write state types and inter-operator access scope for managing shared states among different operators.
Multi-Query Optimization.Ray et al. [63] introduced the SPASS (Scalable Pattern Sharing on Event Streams) framework, which optimizes time-based event correlations among queries and shares processing effectively.The optimizer identifies a shared pattern plan, maintaining an optimality bound.The runtime then uses shared continuous sliding view technology for executing the shared pattern plan.A sequence transaction model on shared views defines the correctness of concurrent shared pattern execution.SPASS doesn't modify existing states but selects, inserts, and deletes shared states like sliding views.Ordering properties are crucial for maintaining the correct order of pattern queries.Event ordering constraint preserves data stream order, while operation ordering constraint is less important as sharing is among queries.ACID properties maintain consistency and correctness of shared states like sliding views.State management properties need readwrite state types and global access scope for managing shared states among pattern queries.However, some implementation details are not specified in the original paper (e.g., sliding views' data layout, key used for searching shared sliding views).

Deterministic Stream Operations.
Handling out-oforder streams is often a performance bottleneck due to the conflict between data parallelism and ordersensitive processing.While data parallelism improves throughput by processing events concurrently, it can cause events to be handled out-of-order.Most solutions use locks or non-lock algorithms like sorting [86].Brito et al. [21] proposed an interesting non-lock approach using software transactional memory (STM) for stream processing.They model processing a batch of input data at order-sensitive operators as a transaction and pre-assign commit timestamps, effectively imposing order.Events received out-of-order or conflicting are processed in parallel optimistically but aren't output until all preceding events are completed, ensuring consistent operator states.Ordering Properties are crucial for managing out-of-order streams, with event ordering constraint needed to maintain data stream order.Operation ordering constraint is less relevant.ACID Properties maintain correctness and consistency of shared mutable states, especially when handling out-oforder and conflicting events.State Management Properties require read-write state types and intra-and inter-operator access scope for managing shared states within and among different operators.
Prioritizing Query Scheduling.Handling potentially infinite data streams requires continuous queries with window constraints to limit tuple processing.Most implementations execute sliding window queries and window updates serially, implicitly assuming a window cannot be advanced while accessed by a query.Golab et al. [37] argue that concurrent processing of queries (reads) and window-updates (writes) is necessary for prioritized query scheduling to improve answer freshness.They model window updates and queries as transactions with atomic sub-window reads and writes, which can lead to read-write conflicts.Golab et al. [37] prove traditional conflict serializability is insufficient and define stronger isolation levels restricting allowed serialization orders following event ordering.Ordering Properties are crucial for prioritizing query scheduling, with event ordering constraint ensuring correct data stream order.ACID Properties maintain correctness and consistency of shared mutable states when handling concurrent reads and writes.State Management Properties require read-write state types and inter-query access scope for managing shared states among different queries and window updates.

Concurrent Stateful Processing
In this scenario, application workloads consist of both ad-hoc and continuous queries, which may access and modify common application states for future reference [22].We will discuss three representative applications in the context of concurrent stateful processing: ad-hoc queryable states, concurrent state access, and active complex event processing, focusing on the properties of TSP required by each application.
Ad-hoc Queryable States.Ad-hoc queries, or snapshot queries, can be submitted to an SPE anytime, executed once, and provide insights into the system's current state.They may be used to obtain further details in response to continuous query result changes.In Botan et al.'s example [19], real-time sensors generate temperature measurements to ensure temperature-sensitive devices operate within design specifications.When a temperature reading falls out of the operating range, it triggers an alert.The SPE must ensure table updates and stream temperature readings are executed in the correct order, demanding event and operation ordering constraints.To maintain the specifications table's integrity and prevent data corruption, ACID Properties are necessary.The state is read-write, as the table needs updates, and the access scope is global, as all incoming temperature readings need to probe the table.Delivery Guarantee and Fault Tolerance are vital for ensuring accurate temperature reading processing and system recovery from potential failures.
Concurrent State Access.In applications like Ververica Streaming Ledger [3] (SL), operators like parser, deposit, transfer, and sink may need to share access to states, such as account and asset data.To process transactions correctly and maintain data consistency, event and operation ordering constraints are crucial.ACID Properties are necessary to ensure shared state accuracy and prevent data corruption during concurrent access.The state is read-write, as the account and asset data need updates, and the access scope includes intra and inter-operator, as multiple operators and their replica instances access and modify the shared stat.Delivery Guarantee, Fault Tolerance, and Durability are critical for maintaining accurate and consistent transaction processing.CAP Theorem considerations must be taken into account when designing the system to balance consistency, availability, and partition tolerance.
Active Complex Event Processing.In the realm of stream processing, active complex event processing is a method that continuously monitors and analyzes a series of real-time events to detect certain patterns or sequences.Wang et al. [81] have applied this concept to a hospital infection control application.The system uses sensor devices to generate real-time data on healthcare workers' (HCWs) behaviors such as "exit", "sanitize", and "enter".These events are then analyzed by pattern queries that aim to detect any violations of hospital hygiene rules.The status of all HCWs, whether static or dynamic, is stored in tables.In this application, it is crucial to maintain the correct order of events and handle concurrent accesses and updates during stream execution.This requires event ordering constraint and ACID Properties to ensure data consistency and prevent conflicts.The state management in this scenario involves read-write states with inter-query access scope, as multiple pattern queries may read or update the tables concurrently.Reliability and delivery guarantee properties, such as delivery guarantee, fault tolerance, and durability, are essential for accurately and consistently detecting violations of hospital hygiene rules.

Stream and DBMS Integration
The integration of SPEs with DBMSs is becoming increasingly important [73].Scenarios such as stream data ingestion (i.e., Streaming Ingestion), implementing OLTP queries in alternative ways (Streaming OLTP), and mixed stream and analytic queries (Streaming OLAP) can be well supported by TSP systems.In the following sections, we discuss each of these scenarios and their requirements concerning TSP properties.
Streaming Ingestion.Streaming ingestion is an essential process for organizations handling large volumes of data, as it enables more timely access to incremental results compared to traditional batch ingestion.This approach processes smaller microbatches throughout the day, which requires proper management of ordering and state properties.A notable example by Meehan et al. [52] involves self-driving vehicles, where the value of sensor data decreases over time.In this case, timely processing and storage of time series data are critical for making valuable decisions.The authors adapt TPC-DI [62], a standard benchmark for data ingestion, to assess streaming ingestion effectiveness while considering new data dependencies introduced by breaking large batches into smaller ones.In this scenario, maintaining the correct order of time series data is crucial, necessitating event ordering constraint.ACID properties are required to ensure the correctness and consistency of ingested data, especially with high sample rates and large data volumes.Read-write state types are needed for efficient management and persistence of ingested data.Delivery guarantee is essential for processing and persisting ingested data accurately and consistently in near real-time.Additionally, durability is necessary to ensure data availability for analysis and decision-making, even after a system failure or outage.
Streaming OLTP.Streaming OLTP addresses traditional OLTP workloads using streaming queries.Chen and Migliavacca [29] propose StreamDB, a TSPbased system.Streaming OLTP requires ACID Properties, State Management Properties (e.g., database partitioning), and fault tolerance.StreamDB uses three operators in a streaming query: 1) Source operator, receiving transactions and sending them to downstream data operators; 2) Data operator, managing a portion of a database, executing transactions, and producing results; 3) Sink operator, receiving transaction responses.StreamDB reduces lock contention by distributing the database among multiple data operators.However, creating an optimal stream dataflow graph for diverse OLTP workloads remains an open question.In this scenario, operation ordering constraint is crucial for correct transaction processing and minimizing lock contention.ACID properties ensure database correctness and consistency during transaction processing.Read-write state types are required for managing the database and transactions, while maintaining consistency.Consistency, Durability, and Fault Tolerance are vital for accurate and consistent transaction processing and for maintaining database consistency even after system failures or outages.
Streaming OLAP.Organizations often need real-time analysis of data streams for immediate decision-making, and several related applications have been described in the literature [20,39,68].The Huawei-AIM workload [20] features a three-tier architecture with storage, an SPE, and real-time analytics (RTA) nodes.RTA nodes push analytical queries to storage nodes, merge partial results, and deliver final results to clients.To meet the service level objective (SLO), a consistent state (or snapshot) must not be older than a certain bound.In this scenario, event ordering constraint ensures correct analytical query processing.ACID properties can be relaxed (e.g., snapshot isolation) to maintain data correctness and consistency.Read-write state types manage the database and ensure the consistent state meets the SLO.Delivery Guarantee, Consistency, Durability, and Fault Tolerance ensure accurate query processing, data persistence, and system recovery from failures.

Robust Stream Processing
In addition to requirements such as scalability and low latency, many critical streaming applications demand SPEs to recover quickly from failures [71].Consequently, considerable effort has been dedicated to achieving fault tolerance in SPEs.We discuss previous attempts to employ transaction-like concepts to ensure high availability and fault tolerance in stream processing, focusing on their demands for properties of TSP discussed in Section 3.1.
Shared Persistent Storage.MillWheel [9] uses an event-driven API for stateful computations and stores input and output data persistently.It relies on remote storage systems like BigTable [27] for managing state updates and handling fault tolerance through data replication.This relates to Durability in ACID properties and Reliability and Delivery Guarantee properties.MillWheel ensures Atomicity by encapsulating all per-key updates in a single atomic operation.While it enforces operation ordering constraints, strict event ordering constraints are not provided.State Management Properties are vital in MillWheel due to its dependence on shared persistent storage.
Transaction Identifier.Trident's "transactional topology" [51] processes small batches of tuples as a single operation and assigns unique transaction identifiers (TXID), relating to Ordering Properties.TXID, logged in external storage along with operator state, addresses Atomicity and Durability in ACID properties.If TXID mismatch occurs, a batch must be resubmitted, requiring strict transaction processing ordering (operation ordering constraint) and potentially limiting throughput.State Management Properties are essential in this approach, as it depends on read-write states.Trident provides strong Delivery Guarantee and Fault Tolerance, but may lose intermediate results during failures due to disregarding buffered input states.
Fault Tolerance Outsourcing.Ishikawa et al. [42] propose integrating fault tolerance into an OLTP engine for data stream processing.This involves backing up data streams in an in-memory database system instead of a file system, addressing Durability in ACID properties and Reliability and Delivery Guarantee properties.It enforces operation ordering constraints, similar to H-Store's state partitioning transaction processing.However, outsourcing fault tolerance can strain the remote store during data spikes, potentially impacting other applications sharing the store.This approach also requires CAP Theorem considerations, as the choice of an in-memory database system might involve trade-offs between consistency and availability.
Remark 4 (TSP is not just nice to have, but sometimes a must) By employing modern SPEs, existing workarounds, such as using external databases to store shared application states, can lead to significant additional programming effort [81], poor performance [53], and even incorrect results [25,37].This problem is exacerbated if more complex shared mutable state storage and retrieval queries, such as range look-ups are further required.In contrast, TSP systematically manages concurrent accesses to shared application states with transactional correctness.This even leads TSP to have the potential to better support traditional database workloads (i.e., OLTP and OLAP) as well.
Remark 5 (TSP-based applications have diverse requirements) Some TSP-based applications do not require insertion and deletion operations at all, while others do not need to update shared mutable states.Also noteworthy is that transactional dependency is rare among applications, which means that in most cases, the input parameters in a transaction are predetermined from the triggering events.Targeting a narrowed application domain, a TSP system can take advantage of these diverse requirements to simplify its design and improve system performance.To date, there is no standard benchmark for TSP systems [74], which must include comprehensive performance metrics, diverse workload features, and meaningful application scenarios.The applications that we list in Table 3 may serve as a starting point for the construction of a standard benchmark.However, more applications may need to be included, arranged according to their particular application's features.

Research Outlook
In this section, we offer a perspective on future research directions of TSP.

Novel Applications
The rise of IoT generates real-time data that needs immediate processing.Traditional big data applications were designed for large static datasets, but modern applications demand more.We foresee novel streaming applications benefiting from TSP solutions as the range of applications served by SPEs widens.Current research, like NebulaStream [84], explores systems meeting these requirements.We discuss various application areas, including online machine learning/stream mining, mixed batch/stream transactional workloads, streaming materialized views, and cloud applications.
Optimization for Stateful Stream Processing.Shahvarani and Jacobsen's IBWJ [66] accelerates sliding window joins by using a shared index data structure, reducing redundant memory access and improving performance.As new tuples arrive, the index structure is updated, raising concurrency control issues.Shahvarani et al. [66] propose a low-cost concurrency control mechanism for high-rate update queries.A TSP system could naturally handle this concurrency problem, providing durability when required.Despite its potential, we are unaware of any practical implementation of this approach.
Online Machine Learning/Stream Mining.The rising demand for data stream analysis necessitates online learning and mining.Current efforts support continuous queries (CQs) referencing non-streaming resources like databases and ML models [59].Model-based streaming systems, such as anomaly detectors, require regular model updates without significantly increasing operational costs [9].Due to the lack of transactional support in traditional SPEs, implementing emerging streaming learning and mining algorithms can be challenging [64].Although existing batch-based ML training (like TensorFlow) may not need to care for inconsistencies in the state they handle, a streaming ML scenario may prohibit such inconsistencies as each input data may be allowed to be used, up to a limited threshold, and any inconsistency may lead to significantly lower training quality.It thus remains an interesting future work to study how those novel training and mining use cases can be supported efficiently in TSP systems, which bring features, such as elastic scaling, fault tolerance guarantees, and shared state consistency to users, even at the virtual space [56].
Mixed Batch/Stream Transactional Workloads.Many enterprise applications, particularly in finance and IoT, generate mixed workloads with continuous stream processing, OLTP, and OLAP.DeltaLake [11] allows streaming jobs to write small objects into a table with low latency and coalesce them into larger objects later.Fast "tailing" reads are also supported for treating a Delta table as a message bus.Tatbul [73] outlines challenges in streaming data integration, including common semantic models, optimization, and transactional issues.These challenges persist due to diverse applications and systems focusing on limited feature sets.

Streaming
Materialized Views.Traditional materialized views (MVs) are not optimized for highvelocity data stream processing, leading to the need for streaming materialized views (SMVs).SMVs must handle high-velocity inputs, update states with random access patterns, and share updated states among concurrent entities.Recent works, such as S-Query [76] and Umbra's continuous view scheme [82], have proposed solutions, but the former lacks strict ACID guarantees, and the latter has yet to be compared with state-of-the-art transactional stream processing systems like S-Store [53], TStream [85], and TSpoon [7].The distinction in use cases drives a clear separation of concerns and further investigation into optimizing SMVs.

Cloud Applications.
Existing SPEs often lack transactional facilities needed for cloud applications that require advanced business logic and coordination [23].One example is stateful function-as-a-service, which demands ACID transactions, global state consolidation, and debugging and auditing capabilities [8,43].These requirements are similar to those of transactional stream processing (TSP).However, it's unclear if TSP systems like S-Store [53] can fully satisfy these requirements.Further exploration is needed, including supporting debugging [45] and isolation [69] in stateful stream processing as microservices.

Novel Hardware Platforms
Modern hardware advancements have made servers with hundreds of cores and several terabytes of main memory available.Such advancements have driven researchers to rethink TSP systems and put emerging hardware platforms to good use [86].Next, we take a closer look at multi-/many-core architectures, non-volatile storage, and trusted computing platforms.
Multi-/Many-core Architectures.Supporting shared mutable states in TSP systems can create bottlenecks due to concurrent state accesses.TStream [85] is a recent example that effectively utilizes multicore CPUs to improve concurrent shared state access performance through dualmode scheduling and a dynamic transaction restructuring mechanism.However, current TSP systems still face scalability challenges with complex workloads and input dependencies.Further research is needed to enhance TSP systems for complex workloads, emerging multi-/many-core architectures with high-bandwidth memory, and multi-node settings while maintaining correctness guarantees [74].
Non-Volatile Storage.Non-Volatile Memory (NVM) is an emerging technology offering byte-addressability and low latency of DRAM along with persistence and density of block-based storage media, but with limited cell endurance and read-write latency asymmetry.Fernando et al. [61] explored efficient approaches for analytical workloads on NVM, potentially laying the foundation for future TSP systems [65].NVMe-based SSDs can deliver high performance in terms of latency and peak bandwidth.Lee et al. [46] investigated performance limitations of SPEs managing application states on SSDs, showing queryaware optimization can improve stateful stream processing on SSDs.Their work is valuable for TSP systems with strict ACID and streaming property requirements, but more research is needed.
Trusted Computing Platforms.The need for low latency and local processing of sensitive IoT data calls for edge stream processing.However, edge devices are vulnerable to attacks due to limited power and computing capacity, posing severe security threats to sensitive data.A potential solution [60] is trusted computing platforms (TCPs), which protect data and code within isolated, encrypted memory areas.Bringing TSP to TCPs is nontrivial and requires further research, particularly in handling limited memory for transactional stateful stream processing [54].Additionally, scaling systems to multiple TCPs in a distributed environment presents challenges due to each computing node's computational limits.

Conclusion
In this survey, we provided a comprehensive overview of Transactional Stream Processing (TSP), and addressed key concepts, techniques, and challenges to be overcome, in order to ensure reliable and consistent data stream processing.We introduced terms, definitions, and a conceptual framework for TSP systems and presented a taxonomy that offers a structured understanding of various approaches and models for integrating transactional properties with streaming requirements.We also discussed several notable TSP systems, each showcasing unique features and design choices that were made, to cater to different application requirements.These systems offer insight and inform designers about the alternative choices they will need to make when designing and implementing a novel TSP system.We highlighted various TSP applications and use cases, such as stream processing optimization, concurrent stateful processing, and stream and DBMS integration.Finally, we explored some open challenges and suggest future directions for TSP research and development, including novel applications and hardware platforms.This survey serves as a valuable resource for researchers and practitioners.It aims to inspire others to pursue work in this field and develop efficient, reliable, and scalable TSP systems for diverse application domains.

Declarations
The authors have no financial or proprietary interests in any material discussed in this article.

Definition 1 (
Unified Transaction) Let D = d 1 , d 2 , ..., d n be a dataset containing both data streams and relational data, and O = o 1 , o 2 , ..., o m be a set of processing operations.

Fig. 5 :
Fig. 5: Illustrations of alternative system architectures of TSP systems.

Table 1 :
Execution mechanisms of TSP systems.

Table 1
Using locks to protect shared states, these methods prevent concurrent access and maintain consistency.Lock-based approaches can be classified into two main types: a) Single-version lock-based: These approaches utilize a single version of the shared state and apply locks to ensure proper transaction execution.The challenge lies in balancing synchronization and performance without causing excessive contention or delays in transaction processing.We discuss three notable examples of single-version lock-based approaches as follows.
Lock-based Approaches: Lock-based approaches ensure the correct execution of transactions by controlling access to shared resources.

Table 2 :
Key characterization of Six Transactional Stream Processing Systems Braun et al.: Braun et al.